HIGH: [Tracking] Implement report NextSteps in Auth

[mountiny]

Whatsnext post here.

Design doc https://docs.google.com/document/d/1gUDVqDdDj0jVOIuFBqPr0D6-vnClB-iztl38PzsiBqE/edit

GH Project https://github.com/orgs/Expensify/projects/154/views/1 CAP issue https://github.com/Expensify/Expensify/issues/406189

Proposal Migrate the report next steps from PHP to Auth

Problem Report next steps are currently calculated on the fly in PHP and are not stored in a database. This means that any commands using report next steps cannot be implemented following the true 1:1:1 API philosophy at the moment. We cannot queue report next steps updates in Auth because we must wait for an Auth command response to trigger the calculation of updated next steps in PHP. Only then can the update be pushed to relevant clients.

Similar to the case of violations, this leads to multiple Auth calls being made during a single API request, breaking the 1:1:1 rule. Many commands are slowed down due to the report next steps computation triggering multiple Auth calls. For example, any action that changes the state or status of a report will trigger a new next step computation. These may be computed multiple times per report as each participant of the expense report might receive different next steps.

It's worth noting that in order to support optimistic and offline calculation of some report next steps, we've implemented the core collect workspace next steps logic in the front-end code of NewDot.

While this project should only focus on migrating what we have from PHP to Auth, it is important to note that this migration is likely to be critical for ensuring that important upcoming projects are 1:1:1-compliant, such as the Search page, where we need to compute the next action for a report efficiently.

Solution At a high level, the solution is to move report next steps to Auth; however, the details need to be fleshed out through predesign and a design document.

At minimum, we should discuss:

• The exact scope of this project.
• The deadline and priority of this project among others.
• How we are going to execute this migration from PHP to Auth to avoid any regressions in OldDot.
• Whether we should keep the report next steps in their own Onyx reportNextSteps key or add them as a key inside the report object.
• How we are going to coordinate with the violations migration that is related to this project (we need to be able to compute report violations to determine report next steps).
• How the timelines for the report next steps audit and this project will align.

cc @JmillsExpensify @cead22

---

Tasks

• [x] Post Proposal (full Problem/Solution statement) in #whatsnext
• [x] Wait at least one full business day, and until the post has a majority (2/3) of positive reactions (👍)
• [x] Paste Proposal in the space above with a link to the Slack thread
• [x] Email [email protected] and paste in the Proposal
• [x] Host a pre-design meeting (example) in an appropriate slack channel to discuss any necessary details in public before filling out the High-level of proposed solution section.
• [x] Fill out the High-level overview of the problem, Timeline, Terminology, and High-level of proposed solution sections of the Design Doc
• [x] Email [email protected] (continue the same email chain as before - your last message should be the WN Proposal) with the link to your Design Doc containing your high-level problem and solution
• [x] Add the DesignDocReview label to get the High-level overview of the problem and High-level of proposed solution section reviewed
• [ ] Respond to any questions or concerns and bring up blockers in Slack to get a consensus if necessary
• [ ] Confirm that the doc has the minimum necessary number of reviews before proceeding
• [ ] Host another pre-design meeting in the appropriate slack channel to ask for engineering feedback on the technical solution.
• [ ] Fill out the Detailed implementation of the solution and related sections.
• [ ] Re-add the DesignDocReview label to this issue
• [ ] Respond to any questions or concerns and bring up blockers in Slack to get consensus if necessary
• [ ] Confirm that the doc has the minimum necessary number of reviews before proceeding
• [ ] Email [email protected] one last time to let them know the Design Doc is moving into the implementation phase
• [ ] Implement the changes
• [ ] Add regression tests so that QA can test your feature with every deploy (instructions)
• [ ] Send out a follow up email to [email protected] once everything has been implemented and do a Project Wrap-Up retrospective that provides:
  • Summary of what we accomplished with this project
  • What went well?
  • What could we have done better?
  • What did we learn?