Adds additional check of keyType to avoid using an invalid type for eager load constraints #16440
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We've recently run into an issue eager loading an optional belongsTo relationship when our primary keys are uuids. Our issue happens when our optional belongsTo relationship is attempted to be eager loaded is not set, and a 0 is returned for the eager model key, and that is an invalid uuid. I know that it is recommended to use incrementing false to avoid this issue, but our codebase uses string uuids generated at the database layer (postgres) rather than the application layer, so technically we needed $incrementing to be set to true (since the database was handling "incrementing" in our case), however our ID type was string rather than int.
I've added this fix that will additionally check that your model's incrementing keyType is an int, before using 0 as the eager loaded model key. keyType was implemented here for another uuid related issue.
This PR is also to help resolve this issue that I opened yesterday. I believe this fix to be the safest way to address the issue without causing breaking change.