[MS-1379] Don't crash on huge metadata

[BurningAXE]

JIRA ticket
Will be released in: 2026.2.0

Root cause analysis (for bugfixes only)

First known affected version: at least since the last navigation refactoring

• Calling app can send in the metadata whatever extra info they want
• When this data is ~ 200K (!) we accept and pass it to OrchestratorFragment as argument
• OrchestratorFragment has 3 lazily initialized VM (loginCheck, clientApi, orchestrator)
• When app is minimized, each VM saves the fragment args in addition to a few more copies from the fragment and Nav controller
• This leads to the saved state Bundle exceeding the max size of 1MB
• KABOOM

Notable changes

• Instead of doing risky changes and jumping through hoops, we simply don't pass intent data as fragment args but read it directly through the activity
• This avoids all the data copies on saving state while having no down sides

Testing guidance

• Send an Intent with at least 200K metadata (I've made a modification in Intent Launcher that does this as otherwise copy-paste buffer cannot handle so much data)
• Wait for SID to open and process the request (e.g. reach the Consent screen)
• Minimize it
• Bring it back - should still be on the same screen which means it didn't crash

Additional work checklist

• Effect on other features and security has been considered
• Design document marked as "In development" (if applicable)
• External (Gitbook) and internal (Confluence) Documentation is up to date (or ticket created)
• Test cases in Testiny are up to date (or ticket created)
• Other teams notified about the changes (if applicable)

[Copilot]

Pull request overview

Fixes a crash caused by oversized navigation arguments/saved-state bundles when caller apps send very large metadata in the launch Intent, by no longer passing Intent data through NavArgs and instead reading it directly from the hosting Activity.

Changes:

• Removed requestAction / requestParams navigation arguments from the orchestration graph.
• Stopped initializing the orchestration graph with fragment args in OrchestratorActivity.
• Updated OrchestratorFragment to read Intent.action and Intent.extras from the activity at runtime (and populate caller-package info there).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
feature/orchestrator/src/main/res/navigation/graph_orchestration.xml	Removes orchestration fragment args so large metadata isn’t duplicated into fragment arguments.
feature/orchestrator/src/main/java/com/simprints/feature/orchestrator/OrchestratorFragment.kt	Reads action/extras from Activity.intent and sets caller package info without using NavArgs.
feature/orchestrator/src/main/java/com/simprints/feature/orchestrator/OrchestratorActivity.kt	Initializes nav graph without passing Intent data as fragment args.

---

You can also share your feedback on Copilot code review. Take the survey.

[alexandr-simprints]

Don't see any problems with it at the first glance. What Intent Launcher version supports sending large amount of data to SID?

[BurningAXE]

What Intent Launcher version supports sending large amount of data to SID?

My local one :D But if it's going to be useful for more than a one-off, I can push the changes.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[luhmirin-s]

Nit-pick: this syntax is a bit confusing and hides the type, I would prefer it a bit more explicit:

private val intentAction: String
   get() = requireActivity().intent.action.orEmpty()

It could also be lazy, as there calling intent shouldn't change.