mobile - update claim request decision response

[aherzberg]

Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.

Summary

the new Lighthouse endpoint returns a boolean success rather than the job id. FE doesn't use the id so for backwards compatibility we're keeping the Job id field and just put string of success or failed for debugging purposes.

Related issue(s)

department-of-veterans-affairs/va-mobile-app#6007

Testing done

• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing
• Describe the tests completed and the results

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas)

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[kpethtel]

Looks like CI is failing and I suspect it's because we're breaking legacy functionality.

On a side note, I have absolutely no idea why we're returning a jid, but we do it in a number of places in the app. The jid is almost surely unusable by the mobile app. It's unfortunate that we've established this pattern because now we're stuck with jid in the response schema unless we want to version the endpoint to phase it out. Which I think is worth consideration.

[kpethtel]

I think this will break legacy functionality.

[aherzberg]

oh right. fixed

[kpethtel]

I think this would be simpler as:

        jid = if Flipper.enabled?(:mobile_lighthouse_claims, @current_user)
                  response = lighthouse_claims_proxy.request_decision(params[:id])
                  adapt_response_state(response)
                else
                  evss_claims_proxy.request_decision(params[:id])
                end

[kpethtel]

I think adapt_response_status or adapt_response might be a more accurate name.

[aherzberg]

works for me. fixed

[kpethtel]

🚀