BUG - sev-3 - All - Claims: 'info needed' label persists until logout for claims with decision requested/5103 submitted

[TKDickson]

What happened?

During the same session that you submit a 5103/request a decision on a claim, they'll still display in the claims history list as "more info requested" (if you can't access that video link, try the file in the screenshots section below). Which is somewhat alarming, because you go to the claim details and don't have the opportunity to submit anything.

Logging out and back in again, we'll correctly remove the label from the claim in the claims history list.

Specs:

• Device:
• OS:
• User Account:
• Accessibility State:

Steps to Reproduce

Desired behavior

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See Bug Tracking for details on severity levels

• Impact: High Low
• Frequency: High Low

• 3 - Low
• 2 - High
• 1 - Critical

Linked to Story

Screen shot(s) and additional information

ScreenRecording_10-16-2024.09-40-40_1.MP4

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

• Steps to reproduce are defined
• Desired behavior is added
• Labels added (front-end, back-end, global, Health, relevant feature, accessibility, etc)
• Estimate of 1 added (for front-end tickets)
• Added either to the relevant feature epic (if found during new feature implementation), or the relevant team's bug epic (Global, Health & Benefits, API, QART)

[Sparowhawk]

@TKDickson is a log out required or does it fix itself if you back out of the list screen to the benefits category landing screen and go back into claims? If it's the latter then it's that we aren't updating the query correctly manually for the list view to refresh itself.

[TKDickson]

@Sparowhawk I was only seeing it on logout. I did exit the list page and come back in again -- but I don't remember if it was going all the way out to the benefits landing screen, or if it was just the 'claims history' and 'claims letters' menu page, when I was checking the 'leave and come back' workflow. Would that make a difference either way?

[Sparowhawk]

No it would not make a difference as long as you backed out one screen in the navigation and then reentered the list.

This may be a BE data not updated yet issue

[jennb33]

12/11/2024 - @kellylein @timwright12 @oddballpete @Eallan919 @ATeal @TKDickson The MFS team will be taking this ticket into Sprint 7, (12/14/2024-12/27/2024)

[jennb33]

12/11/2024 - Therese added video per Matt's request, this is in progress now.

[jennb33]

12/12/2024 - this was blocked because of an access issue. Convo in Slack, need to review this behind a feature flag. Matt is continuing with his testing.
Matt said: Just got a message back from Therese regarding 9902, here’s what she said:

“Short explanation is that if they're flipping that feature flag relatively soon (which it sounds like they will), then the bug will likely no longer be relevant/happen in the app.

I'd mark it as paused/blocked until that's resolved"

Moving this ticket out of Sprint 6 and into Blocked until we have confirmed that the FF has been flipped.

[matt-guest-wilcore]

I manually flipped the feature flag to test locally (submitEvidenceExpansion flag in remoteConfig) and documented the process from the original video. It looks like the feature flag doesn't solve the issue described in the ticket.

I'd also like to point out this comment thread in the DSVA slack channel that is relevant to this issue as there was a lot of discussion there. More specifically, Jacob expressed some concern about the ticket. I figured I'd mention this so we can best determine how to move forward.

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-01-02.at.14.55.54.mp4