deps: Bump github.com/reearth/ygo from 1.48.0 to 1.49.5

[dependabot]

Bumps github.com/reearth/ygo from 1.48.0 to 1.49.5.

Release notes

Sourced from github.com/reearth/ygo's releases.

v1.49.5 — a rejected auth token is terminal at every write site

v1.49.5

Who is affected: anyone using provider/client with Options.Token against a server that can reject it. If you do not set Token, nothing here changes for you.

v1.49.3 fixed a rejected authentication token being sent twice. It fixed most of it. The client announces its token and sends its opening sync message without waiting, and v1.49.3 taught both of those writes to notice a rejection that had already arrived. But the client also answers the server: when the server asks what the client has, the client replies — and that reply is sent in the same instant the rejection may be arriving. When it was, the reply failed to send, the failure looked like an ordinary network glitch, and the client reconnected with the same refused token.

So the symptom is the same as before, through a different door: two failed authentication attempts instead of one. As before there was no infinite retry, no hang, and no data loss — Connect still returned ErrAuthRejected and stopped. It matters if your server counts failed authentications toward rate-limiting or account lockout.

What changed. The check now lives in one place that every send goes through, instead of being attached to two of them. There turned out to be five such sends, not the two the previous fix hardened — a test that simply counts them now fails if a new one is added without the check, which is how this problem reached a release twice.

The same change removes a subtler problem in the previous fix: it read the connection directly while the client's own reader was already reading it, which the WebSocket library does not allow. That is also why it worked only sometimes — the two readers competed for the very message the check needed. It now asks the existing reader instead.

Present since v1.48.0, and only narrowed by v1.49.3. It kept failing our own test suite intermittently after that release, which is how it was caught.

v1.49.4 — capped backoff for a failing compaction, plus a SQLite driver bump

v1.49.4

Who is affected: anyone using the built-in websocket.MemoryPersistence whose compaction can fail. In practice that means a corrupt stored record the merge cannot fold. If your folds succeed, nothing here changes for you — the healthy path is byte-for-byte the same cadence it always was.

MemoryPersistence batches its housekeeping: every so many writes it folds a room's accumulated update records back into one. When that fold failed, it was retried on every subsequent write instead of waiting for the next batch. Each retry re-read and re-merged the whole log — work the previous failure had already shown would not succeed, over a log that only grew.

... (truncated)

Changelog

Sourced from github.com/reearth/ygo's changelog.

[1.49.5] — 2026-09-02

Fixed

• provider/client: a rejected auth token could still reach a second attempt. v1.49.3 (#238) taught the two PROACTIVE handshake writes — the Auth frame and SyncStep1 — to recognise a rejection that was already sitting unread when the write failed. But the client also writes in RESPONSE to the server's handshake: reading the server's own SyncStep1 makes it answer with a SyncStep2 reply, and that write is in the same race. When the rejection won it, the reply write failed with EPIPE, surfaced as an ordinary retryable I/O error, and runReconnectLoop dialled again with a token the server had already refused.

  Two of the session's FIVE write sites were covered; the SyncStep2 reply, the awareness-query reply, and flushLane's own write (which sends a local edit queued while the handshake is still in flight) were not. The classification now happens in a single place that every write site reaches.

  A source-level guard, TestUnit_EveryWriteSiteClassifiesAuthRejection, now asserts that every error-checked connection write routes through it. This bug reached main twice by the same mechanism — a write site nobody had written a behavioural test for — and a behavioural test can only ever cover the sites someone thought of. The guard caught the flushLane site during this very change, after it had already been missed once.

  The fix also removes a latent contract violation introduced with #238's: classifyHandshakeWriteErr called ReadMessage on the connection while the read-pump goroutine was also in ReadMessage, which gorilla explicitly forbids ("no more than one goroutine calls the read methods"). That is also why it was unreliable — the pump and the classifier raced for the very frame the classifier was looking for, so whichever lost saw nothing. classifyWriteErr instead consults the pump's existing channels, which is race-free: frame handlers run from runLoop's own select, so there is exactly one consumer at any moment.

  Impact is unchanged from #238 and still limited: the connection terminated correctly with ErrAuthRejected, so there was never an infinite retry, hang, or data loss. A rejected client made two authentication attempts instead of one, which matters where a server counts auth failures for rate-limiting or lockout.

  Present since v1.48.0, and only narrowed by v1.49.3. It kept failing TestClient_Auth_WrongTokenIsTerminal intermittently on main after that release — reproduced here at authCalls=2 on run 46 of 400, reporting send sync step 2 reply: ... write: broken pipe. The new TestClient_Auth_RejectionSurvivesSyncReplyWriteFailure forces that timing deterministically. Mutation-checked in both directions: unguarding the reply site fails only the new test while #238's still passes, and unguarding the proactive writes fails only #238's — so the earlier test structurally could

... (truncated)

Commits

• 34882d8 fix(client): classify a rejected token at every write site, not just two (#23...
• 28b7f3e docs(readme): lead with code, and stop duplicating the changelog (#241)
• 85dd1aa fix(websocket): back off a failing MemoryPersistence fold instead of retrying...
• f987dfe fix(client): a rejected auth token could reach a second attempt (#238)
• ec42817 docs: release notes for v1.49.2 (#237)
• f06a1a3 test(crdt): a benchmark that can actually see the observed-transaction cost (...
• 2355ac1 fix(crdt): ApplyUpdateV2 silently dropped content on GC structs (#235)
• ac9cd00 fix(websocket,client): append-then-compact MemoryPersistence (#186); shutdown...
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Labels

The following labels could not be found: dependencies, go. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[dependabot]

Superseded by #141.