Hello @AjitKumarC17810417
I looked into this, and I don’t think what you’re seeing is a configurable “duration” setting on the error banner. I checked the Banner component (Cosmos React Core) that renders these inline messages in Constellation, and it has no built-in auto-dismiss/fade timer at all.
Its props are limited to variant, heading, messages, and onDismiss (which only fires on a manual click of the dismiss/× button). There’s no duration/dismissAfter/autoHideDuration knob anywhere on it. So this isn’t a timing value that can be tuned to “last longer”, the banner component itself never times out on its own.
What I suspect is actually happening: the banner isn’t fading, it’s being unmounted. When the assignment-open call comes back with a lock conflict, the portal shows the error, but the surrounding view is likely also reacting to that same failed response for e.g., falling back to a different render (redirecting to the case view, retrying the fetch, or swapping the work area) because the assignment couldn’t open. That fallback replaces the DOM subtree the banner lives in, so it disappears almost instantly, not because of a fade, but because its container gets torn down underneath it.
Your own observation actually supports this well: the error persists longer when opened via the “Go” button from My Tasks vs. directly in the Self-Service portal. If this were a genuine timer-based fade, the entry point shouldn’t matter. The fact that it does points to different navigation/container code paths being involved, with one triggering a faster fallback/redirect than the other.
A couple of things worth checking to confirm this before escalating:
- Open React DevTools (or just the Elements panel) on the banner’s container the moment the lock error appears, and watch whether that container remounts right as the message vanishes.
- Watch the Network tab for a second request firing immediately after the lock-conflict response (a retry, a case refresh, a redirect), and see if its timing lines up with the ~150–300ms disappearance.
Since there’s no supported prop to extend the banner’s display time, and this looks like an app-shell/harness timing behavior rather than something app-level configuration can fix, I’d raise this with Pega support rather than continuing to search for a setting. I don’t believe one exists to find.
Hope that helps narrow it down.
Regards
JC
