Getting these errors in the log
Dictionary: Server rejected a clear operation, but the local dictionary version doesn't match the server's. This is a bug!! (5, 4)
Anyway I can work around these? Anything I can do to avoid it?
9 Replies
Hi @Niv. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The error message you’re seeing—“Dictionary: Server rejected a clear operation, but the local dictionary version doesn't match the server's. This is a bug!! (5, 4)”—indicates a version mismatch between the local and server copies of a transactional collection (such as StringKeyDictionary) when attempting a clear operation. This typically happens if the collection was modified by another client before your clear request reached the server, causing the server to reject your operation.
How to avoid this:
- Minimize concurrent modifications: Since transactional collections like StringKeyDictionary reject operations if the collection changes before your operation is processed, try to avoid having multiple clients modify the collection at the same time, especially before a clear operation.
- Handle rejections gracefully: The API provides a completion handler for operations like
To avoid this error, reduce simultaneous modifications to the collection, use the completion handler to detect and handle rejections, and consider if a non-transactional collection better fits your use case. If the error persists and is disruptive, you may want to reach out to the Normcore team for further assistance, as the message itself suggests it may be a bug in rare cases. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
Clear, which tells you if the operation succeeded. You should use this to detect failures and, if necessary, retry the operation or update your UI accordingly.
- Design for contention: If you expect frequent concurrent modifications, consider whether a non-transactional collection (like RealtimeSet or RealtimeDictionary) might be more appropriate, as these use a last-client-wins approach and are less strict about versioning.
Here’s what the documentation says about transactional collections:
Transactional collections do not reflect a change to the collection until the server has confirmed the change. They also reject your change if another client has modified the same key before your change is received by the server. This is implemented by storing a version for the collection and for each key internally.And for StringKeyDictionary:
— Room > Collections
This operation will be rejected if any keys have been modified before the clear operation reaches the server.Summary:
— StringKeyDictionary Reference
To avoid this error, reduce simultaneous modifications to the collection, use the completion handler to detect and handle rejections, and consider if a non-transactional collection better fits your use case. If the error persists and is disruptive, you may want to reach out to the Normcore team for further assistance, as the message itself suggests it may be a bug in rare cases. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@269927864265211906> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
This looks like a bug, what version are you on and are you able to send us a repro?
we're on latest (2.15.5). Our repro is currently our whole project, I'll need to allocate time to repro in a separate small one - which I am unlikely to have
My best guess here is that someone inserted a key in between when you called clear and received their latest insert operation. I think the “This is a bug!” part of the log is wrong.
Could be. We’re not seeing any actual bug besides the log
@Niv we were able to create a repro. we'll have a fix out in the next few weeks.
Nice 👍
This fix was deployed. It ended up being a serverside-only change. However, no functionality changed. It was working correctly, just outputting an error log in a scenario where everything was working fine.