Repository navigation
fix(chat): stop waits and first messages from misleading the assistant - #76
Merged
Merged
Conversation
… end the next one One click on a portal reported breadcrumbs, then location. The first ended a wait, and the second, left in the buffer, ended the next wait at once: a judged run's person got three instructions in a row without acting. An event within a second of the one that settled the previous wait is still reported, but no longer settles a wait from the buffer. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Judged runs saw « En attente : … » twice while waiting: once on the wait's chip and once on the activity line. The activity line now says « En attente de votre action… », and the chip names what is awaited. A wait the person interrupted by writing never gets a result, so its chip kept reading « En attente » under later replies. The waits a turn leaves pending are now settled when it ends. The host-events e2e assertions on the activity line follow the new label (not run here: they need the agents dev stack). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
simple-directory issues the anonymous action token with a notBefore delay (8s), on purpose. A judged portal run's first chat message was sent before it and failed with « anonymous action token not yet valid »; the retry on 401 fetched a new token, not yet valid either, and the message was lost. The token is now returned once its notBefore time has passed. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A judged portal simulation: the result of wait_for_user_action listed « draft-validated » first, then the older « unpublished changes: the person must press « Valider le brouillon » » state, which reads as the state that followed the validation. The event that resolved the wait and its followers are now listed in time order. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… of the page The stats tiles render once their request answers: under the load of the full suite, the default 5 s ran out before « Blocked messages (30d) » showed, while the other waits of the test allow 10 to 15 s. It passes on its own. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Fix chat-side defects found by judged portal simulations. Each one fed the assistant (or the person) a false picture of what had happened:
SAME_GESTURE_MS(1 s) of the event that settled the previous wait, a buffered event is still reported but no longer settles a wait.getAnonymousTokennow waits untilnbfplus a 1 s margin.Why: the simulations showed the assistant giving instructions the person had not asked for, describing stale state as current, and losing the first message. All of this read as fabrication, but it came from the client giving the assistant the wrong inputs.
Heads-up:
getAnonymousTokencan now block for up to ~9 s when no prefetch happened beforehand. Callers prefetch on init, so this is usually zero.