Contextual Bar Fails to Open or Update After UI Reload (Cmd+R)

[a-beleg]

When a user triggers the contextual bar via a message action button, the app calls:

modify.getUiController().openSurfaceView(view, { triggerId }, user);

and the sidebar opens as expected . The older method openContextualBarView is deprecated in favor of openSurfaceView and updateSurfaceView . These APIs are provided by the Rocket.Chat Apps‑Engine framework (v1.50.0) .

However, after a client‑side reload (e.g., Cmd+R) the previously obtained triggerId becomes stale, and both of these calls complete without errors but do not render or update the contextual bar . This happens because Rocket.Chat issues a fresh triggerId only at the moment of user interaction—any attempt to reuse an old triggerId is silently ignored .

Steps to reproduce
1. Deploy an app on Rocket.Chat v7.5.1 with requiredApiVersion: "^1.50.0".
2. Click a message action button that invokes openSurfaceView(...) → contextual bar opens.
3. Press Cmd+R to reload the Rocket.Chat client.
4. Click the same message action button again → no sidebar opens, no errors.

Expected behavior

Per the official docs, each time a valid triggerId is provided, the UI methods should open or update the sidebar:

modify.getUiController().openSurfaceView(...);  
modify.getUiController().updateSurfaceView(...);

Each button click should obtain a fresh triggerId and reliably:
• Open the sidebar if not open, or
• Update it if already open.

Even after a reload, clicking the button should always display a sidebar .

Actual behavior

We maintain an isOpen flag per user/room by persisting it with Rocket.Chat’s persistence API (IPersistence/IPersistenceRead) as a RocketChatAssociationRecord under the MISC model (key: forward_view_state_${userId}_${roomId}) and reading it back on each interaction . In our handlers, we do:
1. Read isOpen via read.readByAssociation → boolean.
2. If isOpen === true, call

modify.getUiController().updateSurfaceView(view, { triggerId }, user);
3. Otherwise, call

modify.getUiController().openSurfaceView(view, { triggerId }, user);
await persistence.updateByAssociation(assoc, { isOpen: true }, true);

However, after a client‑side reload (e.g. Cmd+R), the previously issued triggerId becomes invalid and both openSurfaceView and updateSurfaceView fail silently (no exception, no UI change) . Because our persisted isOpen remains true, we always attempt only updateSurfaceView on subsequent clicks—which again no‑ops, leaving the sidebar broken .

Both openSurfaceView and updateSurfaceView calls complete without throwing, but no UI appears. The stored isOpen flag remains true, causing the code to attempt only updateSurfaceView on subsequent clicks—which also fails silently .

Server Setup Information
• Version of Rocket.Chat Server: 7.5.1 (08 Apr 2025) 
• Apps‑Engine Version: 1.50.0 
• License Type: Starter
• Number of Users: 11 (5 online, 6 offline)
• Operating System: (cloud-managed)
• Deployment Method: Cloud (Starter plan)
• Number of Running Instances: 1
• DB Replicaset Oplog: Enabled
• NodeJS Version: 22.13.1 
• MongoDB Version: 6.0 (6.0.21) 
• Support Window: Supported until October 31, 2025 
• Version Support Cycle: Rocket.Chat versions receive support for six months after release 

Client Setup Information
• Desktop App or Browser Version: macOS latest
• Operating System: macOS 15.3.2 (24D81)

Additional context

This bug completely blocks any multi‑step UI workflows that rely on repeatedly opening or updating the contextual bar within a single session. Because the only indicator of an open bar (triggerId) is discarded on reload, apps cannot recover the UI state programmatically. This is critical, not “nice‑to‑have,” for any production app using interactive sidebars.

We ask for one (or more) of the following critical enhancements:
1. Have openSurfaceView / updateSurfaceView return a boolean (or throw) on failure, rather than silent no‑op.
2. Expose an API like isValidTriggerId(triggerId): boolean to let Apps detect expired IDs.
3. Provide a mechanism (event or callback) to inform Apps of a client hard‑reload (Cmd+R), so they can reset state.

Without such changes, Apps cannot reliably manage UI across page reloads, leading to fragile user experiences and constant manual re‑invocation.

Relevant logs

No server‑side errors are emitted; UI calls succeed silently with no visible effect.