Renaming a session now warns you when the new name didn't reach other running sessions, pointing at --debug.
What's wrong with this entry?
A rename that applied locally but failed to reach the shared record of running sessions now says so, and points you at --debug for the cause. It used to fail silently apart from an unrelated line about a PID file.
- The rename result appends the caveat only when the shared record was not updated.
- Also fixes a case where the confirmation printed the internal result object instead of the new name.
Other sessions may still show the old name: the session registry could not be updated (run with --debug for the cause), applied locally but the session registry record was not updated
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.232
Session logs get a place in the managed storage layer
Both mention debug
-
v2.1.228
Agent SDK debug logs can go through the storage layer
Both mention debug
-
v2.1.232
Gateway settings failures now say what actually went wrong
Both mention debug