Skip to content

Conversation

@paulsonnentag
Copy link
Collaborator

When you subscribe to changes on a doc handle the first time the document loads the state on the handle is still "loading" in the change callback even though the document is already loaded.

handle.on("change", () => {
   console.log(handle.state) // logs "loading" when initially loading instead of ready
})

Why is this happening? On each state transition we call #checkForChanges this function which has two responsibilities:

  • checks if we need to emit a change event
  • transitions the state machine from "loading" to "ready" when the document was loaded for the first time

Right now when the document is loaded for the first time #checkForChanges emits a change event and then transitions the state machine from "loading" to "ready". That's why in the callback the state field on the handle is still loading. This pull request fixes this that we first transition into the ready state and then trigger a change event.

@paulsonnentag paulsonnentag requested a review from alexjg July 3, 2025 09:13
Copy link
Collaborator

@msakrejda msakrejda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the bug report and the fix! I have some minor comments, but overall it looks great.


// If we didn't have the document yet, signal that we now do and return
// checkForChanges will then be triggered again by the state machine
// This ensures that when change is triggered the state is set to ready
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the comment: this definitely makes it easier to follow.

@msakrejda
Copy link
Collaborator

I'm pretty sure the CI failure is unrelated: https://github.com/automerge/automerge-repo/actions/runs/16046435722/job/45280996045?pr=453#step:6:797 -- it's an OOM. I'll try restarting the test and see if it's a recurring issue.

@msakrejda
Copy link
Collaborator

@paulsonnentag are you interested in continuing this patch? It looks like the CI OOM is persistent, so we'd need to figure that out, but other than that and the minor cleanup I suggested, I think this is ready to merge, and it seems like a worthwhile change. If not, I can look into getting it over the finish line.

@paulsonnentag
Copy link
Collaborator Author

Thanks for catching that. If you'd take over this PR I'd be very happy

@msakrejda
Copy link
Collaborator

Hmm, so, I think this does break some existing assumptions somewhere. I was able to reproduce the CI failure, partly: the tests appear to hang. I'm guessing maybe we're leaking memory somehow during the hang and eventually we OOM. I do see a slow leak locally. I can take a look at it next week.

@msakrejda msakrejda self-requested a review August 7, 2025 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants