Add session replay id to Sentry Logs

[stefanosiano]

📜 Description

added session replay id to logs, if a replay is running

💡 Motivation and Context

Resolves https://linear.app/getsentry/issue/ANDROID-210/add-sentryreplay-id-to-android-logs

💚 How did you test it?

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[linear]

ANDROID-210 Add `sentry.replay_id` to android logs

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	363.28 ms	438.74 ms	75.46 ms
Size	1.58 MiB	2.10 MiB	535.10 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
b750b96	421.25 ms	444.09 ms	22.84 ms
23d6b12	354.10 ms	408.38 ms	54.28 ms
ee747ae	405.43 ms	485.70 ms	80.28 ms
17a0955	372.53 ms	446.70 ms	74.17 ms
85d7417	347.21 ms	394.35 ms	47.15 ms
d217708	375.27 ms	415.68 ms	40.41 ms
c8125f3	383.82 ms	441.66 ms	57.84 ms
ee747ae	358.21 ms	389.41 ms	31.20 ms
ee747ae	554.98 ms	611.50 ms	56.52 ms
ee747ae	357.79 ms	421.84 ms	64.05 ms

App size

Revision	Plain	With Sentry	Diff
b750b96	1.58 MiB	2.10 MiB	533.20 KiB
23d6b12	1.58 MiB	2.10 MiB	532.31 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
17a0955	1.58 MiB	2.10 MiB	533.20 KiB
85d7417	1.58 MiB	2.10 MiB	533.44 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
c8125f3	1.58 MiB	2.10 MiB	532.32 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB

Previous results on branch: stefanosiano/feat/replay-id-logs

Startup times

Revision	Plain	With Sentry	Diff
f13c41f	343.18 ms	409.56 ms	66.38 ms
9cc652c	367.13 ms	455.27 ms	88.14 ms
df60c47	412.76 ms	475.58 ms	62.82 ms

App size

Revision	Plain	With Sentry	Diff
f13c41f	1.58 MiB	2.10 MiB	533.11 KiB
9cc652c	1.58 MiB	2.10 MiB	533.41 KiB
df60c47	1.58 MiB	2.10 MiB	533.00 KiB

[romtsn]

It's still a bit unclear how to handle it properly with edge-cases (e.g. buffered replay not being sent), let's follow the internal thread and implement this properly after that: https://sentry.slack.com/archives/C03USURCFBJ/p1758210278868829

[stefanosiano]

I've seen that if the replay is in buffer mode, no replay id is set to the scope until it's captured, and then it is converted to session mode
So I think we should never see the sentry._internal.replay_is_buffering attribute set, right?
This means that we are actually never sending the replay id (because it's not set to the scope) when the replay is in buffer mode. Should we change that?

[romtsn]

so I think we can simplify this by quite a bit:

• First get the replay_id from scopes
  • If it's not empty that means all good and we're in session mode (or about to enter it) - hence we don't have to send sentry._internal.replay_is_buffering at all
  • If it's empty - we try to get the replay_id from scopes.getOptions().getReplayController().getReplayId()
    • If it's not empty that means we're in buffer mode - hence we have to send sentry._internal.replay_is_buffering: true
    • If this one is still empty - that means there's no replay being recorded right now and we just don't send any of that

This way we wouldn't have to keep replayType in the scope either. How that sound?

[stefanosiano]

@romtsn do you like it now? 😄

[romtsn]

one nit about nullability