I'm seeing this issue with non-background reloading (I have shouldReloadAll set to true, and after a bit of random navigation to and from a record, Ember starts hitting my back end with requests for a record with a null ID).

This seems like a clear bug — if someone from ember data can give me any guidance about where to dig into this, I can try to learn enough about the architecture to submit a failing test PR or maybe a fix. @bmac maybe?

As an update, the error I see reads like this:

Attempted to handle event `notFound` on <students_ui@model:dos-document::ember2109:null> while in state root.loaded.created.uncommitted

Hi @decasia. Feel free to ping me on the ember community slack. I think a good place to start debugging this would be adding a breakpoint to the store's scheduleFetch to try to figure out where/why Ember Data is initiating the request for a record in the isNew state.

@mcrummey looking at the code you posted, it seems that you are transitioning to the form-design route via this.transitionToRoute("form-design", form.get("id"));. As far as I can see the form doesn't have an ID yet, since it is a new record? I don't know the implementation of the model() hook of the form-design route, but is it possible that it triggers the load of the new record?

Did you have time to dig into this more with the hint @bmac suggested?

ping @mcrummey @decasia

@pangratz @wecc @decasia The form is a new record and the the id is populated with a UUID client side.

So form.get("id") returns something like "ef42540f-7dce-4b40-9b4f-4feb7299f782".

@mcrummey If you already have access to the new record you should be able to pass the record to the transition to bypass the model() hook, like this:

this.transitionToRoute("form-design", form);

That said, having client side IDs with new records should probably not default to true in shouldBackgroundReloadRecord. I'd be open to a PR changing this behavior... @bmac @pangratz what do you think?

@wecc Passing the object works and it does not trigger shouldBackgroundReloadRecord().

This is a bug. I am working on a fix.

This was resolved by the above PR, but we forgot to close it. Closing now :)