fix(ios): recording resume after an interruption by SomePersonFromMars · Pull Request #1257 · software-mansion/react-native-audio-api

SomePersonFromMars · 2026-08-28T11:59:59Z

⚠️ Breaking changes ⚠️

iOS - observeAudioInterruptions(true) no longer replaces native recovery. Native onInterruptionBegin / onInterruptionEnd always run. The flag only enables JS interruption events, which matches the existing AudioManager docs. Apps that subscribed because observing used to skip native resume should not own engine recovery for a recorder (in particular, do not call Recorder.pause() on began - that moves the engine to Paused and disables the native retry). Playback can still pause on began. Native pauses on began, but it does not resume audio contexts.

Introduced changes

Fixes iOS recording that never came back after an interruption. Updated library policy: the same take resumes when the app is, or becomes, foreground. Background restart after the interrupter leaves is best-effort; iOS can still refuse I/O while the app is backgrounded.

Responds to the issue

§1 onInterruptionEnd never activated the session; failure poisoned Idle; no input-node guard

Activate the session before any engine teardown/rebuild (matches startEngine).
On activation or startAndReturnError failure, stay Interrupted and return (do not set Idle). A later retry can run.
If a recorder is attached but the input sink did not materialize, stay Interrupted and treat it as capture lost (do not look like a successful start with no buffers).
shouldResume` according to the docs only refers to playback resume. On the other hand, we choose to resume recording unconditionally, assuming that it has been explicitely registered by the user. The only exception to this policy is when playback shouldn't be resumed: ideally, we would only resume recording and not playback. It is not trivial to implement currently and the usecase is uncommon, therefore it is safer not to resume in such a case.

§2 Docs vs behavior for observeAudioInterruptions

When JS is configured to observeAudioInterruptions, an appropriate handler runs only when AudioEngine actually transitioned to a new state. For example, if the engine was Interrupted, the handler runs on a successful transition to Running.
Native recovery now runs independently of whether JS is observing interruptions, in accordance with the documentation.

§3 No-op setActive:false still ran deactivation

setAudioSessionActivity(false) only calls session-deactivation handling if the session was actually managed and active before setActive. It no longer transitions Interrupted to Paused, which used to disable onInterruptionEnd.

§3 / footnote - resume() / store Recording on a dead engine

resume() still does not have a return type, but it is now guaranteed that isRecording() is true if and only if the audio engine is not in an interrupted state and the recorder is actually running.
According to my experiments and research, it is now most likely never necessary to implement a custom retry policy in JS.
- AudioEngine's onInterruptionEnd recovery after AVAudioSessionInterruptionTypeEnded can still fail. That can happen, for example, due to a race with a higher-priority app or internal iOS privacy policy. In that case we retry once the app returns to the foreground, which is then guaranteed by iOS to succeed.
- At the same time, I can imagine a situation where an active retry policy might be useful, but I am unable to trigger a scenario in which the first background interrupt recovery fails and the next one succeeds.
  - If an iOS privacy policy was the cause, I suppose consecutive retries would finish with the same error. It is hard to judge, though, because this is not well documented.
  - On the other hand, if a race with another app caused the failure, then once that app finishes its activity it typically announces an interruption-ended notification as well, which lets our app try to recover.
- If a reproducible scenario is found in which an active retry policy is necessary, it can be considered again.
- Relatedly, I do not think it is useful for a JS app developer to handle native iOS errors (for the modules affected by this PR) themselves. If there is a use case for that, it can be considered again. Such a feature would require an architectural update, because the codebase is not currently prepared to surface native iOS errors to JS.

Consumer note - mixWithOthers / CannotInterruptOthers

Documented: mixable playAndRecord is required to avoid CannotInterruptOthers when activating in the background, and is not sufficient for background restart. The Record demo enables mixWithOthers with default mode.

Additional useful tweaks and fixes

Retry on foreground. Once recovery from an interruption fails and does not lead to an audio-engine transition, engine recovery is retried when the app returns to the foreground via WillEnterForegroundNotification and DidBecomeActiveNotification. iOS guarantees that a foreground audio start succeeds. The retry uses a cached shouldResume flag.
Generalized handleInputConfigurationChange to handle errors. A failed engine resume now finalizes the audio recorder.
File writers after capture loss. Capture loss closes the current segment. A later successful resume (HardwareChanged) must open a new rotating segment instead of calling rotateFiles() on a writer that is already closed. IOSRotatingFileWriter::reprepareStreamFormat reopens when the inner file is closed; rotateFiles() no-ops if nothing is open.
Player detach on failed startIfNecessary, matching the recorder. A later recorder start must not play leftover source audio.
Record demo: observeAudioInterruptions(true); freeze the waveform on began, unfreeze only on ended.

Docs

New AudioManager subsection "Resume recording after an interruption".
Extended instructions related to iOS audio session configuration.

Manual tests and reproductions used while debugging

This issue is hard to reproduce with automated tests. During research and implementation I used the following manual tests, with the apps/fabric-example app and the included Recorder demo.

Start record; go background; interrupt with Siri; stop record
Start record; go background; interrupt with Siri; tell it to open FabricExample; stop record
Start record; go background; interrupt with meet.jit.si; disconnect; stop record
Start record; go background; interrupt with meet.jit.si; disconnect and close the Safari tab; stop record
Start record; interrupt with FaceTime; stop record
Start record; go background; interrupt with FaceTime; stop record
Record a short take and stop; start exclusive audio (could stay in foreground and accept FaceTime); play the recorded take; end the exclusive audio; end the recorded playback before it ends; record again
Record a short take and stop; start exclusive audio (could stay in foreground and accept FaceTime); play the recorded take; end the exclusive audio; wait until playback ends; record again
Record a short take and stop; start exclusive audio (could stay in foreground and accept FaceTime); play the recorded take and wait until playback reaches the end; end the exclusive audio; end the recorded playback; record again
Record a short take and stop; start exclusive audio (could stay in foreground and accept FaceTime); play the recorded take and wait until playback reaches the end; end the exclusive audio; end the recorded playback; record again (do this step quickly enough after ending the exclusive audio)

Safari WebRTC microphone session side note. One of the most mysterious errors I found, while experimenting with a meet.jit.si interruption, is the following:
Error while restarting the audio engine after interruption: Error Domain=com.apple.coreaudio.avfaudio Code=2003329396 "(null)" UserInfo={failed call=err = PerformCommand(*ioNode, kAUStartIO, NULL, 0)}
It is the result of executing [self.audioEngine startAndReturnError:&error] in AudioEngine's onInterruptionEnd. Code 2003329396 corresponds to the 'what' FourCC, which is AVAudioSessionErrorCodeUnspecified. It is not well documented, and I am unable to resume the session in the background with this error even with multiple active delayed retries, until I return to the foreground. I have two hypotheses that explain it: the first is iOS privacy policy; the second is that the interruption modifies the shared iOS audio session settings, after which a recovery to the original ones is impossible in the background.

I mention it because I thought it was a good example for an active retry, but such a policy does not bear fruit.

Checklist

Linked relevant issue
Updated relevant documentation
Added/Conducted relevant tests
Performed self-review of the code
Updated Web Audio API coverage - N/A (iOS session / engine, not a Web Audio node)
Added support for web - N/A
Updated old arch android spec file - N/A (no TurboModule spec change)

…ting a closed writer

…s actually delivered

Also JS handler is only executed on an engine state change.

…ecorder does

maciejmakowski2003

could you perform the same research on android? in perfect world we would like to provide SotA for interruptions om both platforms.

maciejmakowski2003 · 2026-09-04T11:47:45Z

could you research and add a section about background resume for playback? I am quite sure that below audio session settings allow it.

AudioManager.setAudioSessionOptions({ iosCategory: 'playback', iosMode: 'spokenAudio', })

It is out of scope of this PR, so I will remember to do it in another one.

maciejmakowski2003 · 2026-09-04T11:54:00Z

+- (void)emitInterruptionBeganIfAccepted:(bool)accepted
+{
+  if (!self.audioInterruptionsObserved || !accepted) {
+    return;
+  }
+
+  [self.audioAPIModule invokeHandlerWithEventName:audioapi::AudioEvent::INTERRUPTION
+                                          payload:audioapi::InterruptionPayload{
+                                                      .type = "began", .shouldResume = false}];
+}


let's inline it

Objective C doesn't really have inline methods, because sending messages always happens in runtime via dynamic dispatch. The closest thing we can get would be the following:

inline void privateHelper(MyClass *self, NSString *value) { [self doSomething]; } @implementation MyClass - (void)publicMethod { privateHelper(self, @"Hello"); } @end

I think, though, that it would introduce too much complexity.

maciejmakowski2003 · 2026-09-04T12:08:29Z

+  AudioEngine *audioEngine = self.audioAPIModule.audioEngine;
+
+  if (self.interruptionEndedDelivered && [audioEngine getState] == AudioEngineStateInterrupted) {
+    [self performInterruptionEndOnEngine:audioEngine shouldResume:true];


verify hardcoded shouldResume: true

Please verify the new caching policy.

maciejmakowski2003 · 2026-09-04T12:14:18Z

+  if (!shouldResume && self.inputRegistration == nil) {
+    [self stopEngine];
+    [self rebuildAudioEngine];
+    self.state = AudioEngineState::AudioEngineStatePaused;
+    [self notifyInput:AudioEngineInputNotificationHardwareChanged];
+    return AudioEngineInterruptionEndOutcomePaused;
+  }
+
+  if (![self.sessionManager ensureActive:true error:&error]) {
+    NSLog(@"Error while activating audio session after interruption: %@", [error debugDescription]);
+    return AudioEngineInterruptionEndOutcomeStillInterrupted;


what if we have both player and recorder paused <==> engine paused and interruption happens? does it mean that engine will auto-start after interruption

Please verify thew new more explicit playback/recording resume policy.

github-actions · 2026-09-17T11:57:53Z

WPT non-regression comparison

PASS — no regressions · 0 improved section(s) · overall 3420 → 3420 (0)

Unchanged sections (28)

Spec section	Base pass	Head pass
Processing model	0	0
Other	56	56
AnalyserNode	138	138
AudioBuffer	140	140
AudioBufferSourceNode	218	218
AudioContext	58	58
AudioNode	261	261
AudioParam	680	680
BiquadFilterNode	275	275
ChannelMergerNode	30	30
ChannelSplitterNode	7	7
ConstantSourceNode	64	64
ConvolverNode	203	203
DelayNode	104	104
DestinationNode	0	0
DynamicsCompressorNode	4	4
GainNode	15	15
IIRFilterNode	87	87
MediaElementAudioSourceNode	0	0
MediaStreamAudioDestinationNode	1	1
MediaStreamAudioSourceNode	0	0
OfflineAudioContext	35	35
OscillatorNode	104	104
PannerNode	723	723
PeriodicWave	33	33
ScriptProcessorNode	0	0
StereoPannerNode	102	102
WaveShaperNode	82	82

_{Baseline: 87cca81bff30ee15f3a407008cdc2ee30527ef89 · Candidate: 3c491fc9598984daa379e927a2377c3ddcb86181}

_{Workflow run · this comment is updated on every push.}

…errupted state

…n device that it still works.

Co-authored-by: Maciej Makowski <maciej.makowski2608@gmail.com>

SomePersonFromMars · 2026-09-29T11:02:19Z

could you perform the same research on android? in perfect world we would like to provide SotA for interruptions om both platforms.

@maciejmakowski2003 It seems out of scope of this PR, so I will remember to do it in another one.

mdydek

I think we should in different PR implement also recoverable android from the interruption, because right now the only thing it does is sending event to the js about the interruption which would make both platforms behavior non uniform

mdydek · 2026-10-01T13:39:20Z

 Defaults to `true`.

-Allows the app to play audio in the background on iOS.
+Allows the app to play audio in the background on iOS. Corresponds to adding `audio` to [`UIBackgroundModes`](https://developer.apple.com/documentation/bundleresources/information-property-list/uibackgroundmodes).


Suggested change

Allows the app to play audio in the background on iOS. Corresponds to adding `audio` to [`UIBackgroundModes`](https://developer.apple.com/documentation/bundleresources/information-property-list/uibackgroundmodes).

Allows the app to play audio in the background on iOS.

there is no need to tell about UIBackgrounModes, user does not care about it

It is useful for a programmer for the same reason we point to Apple's documentation in the case of AudioManager.setAudioSessionOptions(): In both cases the settings are merely thin wrappers on top of a native iOS specific functionality. We shouldn't try to explain it in our docs, since we would repeat Apple's docs.

mdydek · 2026-10-01T15:00:55Z

+
+An interruption is the system taking the audio session away due to a phone call, an alarm, or another non-mixable audio session. It deactivates the session and stops the I/O unit. Audio playback and capture therefore stop.
+
+A resume that completes while the app is still backgrounded is possible only when all of the conditions below hold.


Suggested change

A resume that completes while the app is still backgrounded is possible only when all of the conditions below hold.

A resume that completes while the app is still **backgrounded** is possible only when all of the conditions below hold.

lets emphasize that it applies to backgrounded application, because normally there is no need for those condition to be true in order to resume after an interruption

mdydek · 2026-10-01T15:02:23Z

+#### Execution
+
+To complete a background resume, audio I/O must have been started in the foreground, and it must still have been running when the app went to the background. The background audio mode lets that already-running I/O *continue*; it does not allow *starting* audio from the background. iOS treats an `interruption` event of type `ended` as the wake on which a background resume may be attempted. A later background timer is not such a wake. Another app must have released the audio route and the microphone. For recording, the recorder must not have been stopped with [`stop()`](/docs/inputs/audio-recorder#stop), because stopping ends the take.
+
+#### iOS policy
+
+iOS policy determines the overall outcome of restarts. Activating the session and starting I/O are independent steps. An active session does not grant permission to run I/O. Even when every condition above is met, iOS may still refuse the restart: it applies internal checks on why the app is awake. The library therefore does not promise a background restart after a call, Siri, or a similar interruption. Because of this, the library retries with a best-effort strategy when the app returns to the foreground after a failed resume.


I'm not so sure what to do with this section, to me it looks like a wall of text, even though I am familiar with the concept, lets try to spend a little time to include only high-level informations without going into details, which would be unnecessary for normal dev

mdydek · 2026-10-01T15:03:39Z

+- `IOSMode` maps to [`AVAudioSession.Mode`](https://developer.apple.com/documentation/avfaudio/avaudiosession/mode-swift.struct)
+- `IOSOption` maps to [`AVAudioSession.CategoryOptions`](https://developer.apple.com/documentation/avfaudio/avaudiosession/categoryoptions-swift.struct)
+
+Not all `iosOptions` are compatible with every `iosCategory`. Passing an invalid combination to the native API will cause the configuration to fail. Always verify valid category and option combinations in [Apple's AVAudioSession Documentation](https://developer.apple.com/documentation/avfaudio/avaudiosession?language=objc).


it is repeated info with the warning in the setAudioSessionOptions

mdydek · 2026-10-01T15:12:30Z

+        // TODO: Ideally, we would
+        // only resume recording and not playback,
+        // but it would be complex to implement and
+        // the usecase is not common, therefore
+        // not resuming the engine is safer.


why so little comments? they could easily fit in fewer lines

That's right. I looked at other comments in places nearby. I see that they most often end at column 80, so that's what I'd stick to most often.

mdydek · 2026-10-01T15:24:05Z

  reprepareForLiveInput();
 }

+void IOSAudioRecorder::handleCaptureLost()


maybe handleRecordingLost, would be more meaningful

mdydek · 2026-10-01T15:53:17Z

+  if (!resumeEngine) {
+    [self stopEngine];
+    [self rebuildAudioEngine];
+    self.state = AudioEngineState::AudioEngineStatePaused;
+    [self notifyInput:AudioEngineInputNotificationHardwareChanged];
+    return AudioEngineInterruptionEndOutcomePaused;
+  }
+
+  if (![self.sessionManager ensureActive:true error:&error]) {
+    NSLog(@"Error while activating audio session after interruption: %@", [error debugDescription]);
+    return AudioEngineInterruptionEndOutcomeStillInterrupted;
  }

  [self stopEngine];
  [self rebuildAudioEngine];


if we resume or not, either way we stop and rebuild, so we can do it on top and not repeat it

The problem is that the resumeEngine branch also tries to ensureActive on the sessionManager before stop and rebuild audio engine. An alternative shape is the following:

if (resumeEngine && ![self.sessionManager ensureActive:true error:&error]) { NSLog(@"Error while activating audio session after interruption: %@", [error debugDescription]); return AudioEngineInterruptionEndOutcomeStillInterrupted; } [self stopEngine]; [self rebuildAudioEngine]; if (!resumeEngine) { self.state = AudioEngineState::AudioEngineStatePaused; [self notifyInput:AudioEngineInputNotificationHardwareChanged]; return AudioEngineInterruptionEndOutcomePaused; }

But I think that the cognitive load of resumeEngine condition appearing twice and the if statement with an && in the condition is not worth it. I think that it is easier to read if the branches are expressed explicitely.

mdydek · 2026-10-01T16:01:20Z

+                              selector:@selector(handleWillEnterForeground:)
+                                  name:UIApplicationWillEnterForegroundNotification
+                                object:nil];
+  [self.notificationCenter addObserver:self
+                              selector:@selector(handleDidBecomeActive:)


Suggested change

selector:@selector(handleWillEnterForeground:)

name:UIApplicationWillEnterForegroundNotification

object:nil];

[self.notificationCenter addObserver:self

selector:@selector(handleDidBecomeActive:)

selector:@selector(retryInterruptedRecordingIfNeeded:)

name:UIApplicationWillEnterForegroundNotification

object:nil];

[self.notificationCenter addObserver:self

selector:@selector(retryInterruptedRecordingIfNeeded:)

i think the name of event gives enough context about what it is being responded to, so we can call this function directly without serving as "proxy"

I can imagine that in the future we might want to add more tasks that we would like to execute on such a notification. In such a case it might be tempting to add those under retryInterruptedRecordingIfNeeded for example, because it works. In any case, the point is to emphasize that even though for now there is only one task on that handle, it isn't necessary.

mdydek · 2026-10-01T16:02:26Z

+- (void)emitInterruptionBeganIfAccepted:(bool)accepted
+{
+  if (!self.audioInterruptionsObserved || !accepted) {
+    return;
+  }


if we immediately return if accepted is false we can check this condition in the caller and not call this function at all

this way we also omit awkward ifAccepted part

SomePersonFromMars added 6 commits August 20, 2026 14:18

fix: issue #1220 suggested onInterruptionEnd update

2c35596

fix: minor tweaks to previous flawed patch

0547b09

fix: add mixWithOthers to Recorder demo

b9fd96e

fix: generalize handleInputConfigurationChange() to handle errors

b93c5c1

fix: retry AudioEngine resume from interrupt when back foreground

523e5a4

fix: reopen a new rotating segment after capture loss instead of rota…

1bfa489

…ting a closed writer

SomePersonFromMars force-pushed the fix/ios-recording-interrupted branch from 36d372e to 900e04b Compare August 28, 2026 12:06

fix: retry AudioEngine resume only happens when interruption ended wa…

6283fb7

…s actually delivered

SomePersonFromMars force-pushed the fix/ios-recording-interrupted branch from 900e04b to 6283fb7 Compare August 28, 2026 12:08

SomePersonFromMars added 2 commits August 31, 2026 12:19

fix: always perform native recovery after interruption notification

bc74d58

Also JS handler is only executed on an engine state change.

feat: observeAudioInterruptions(true) in the Record demo

f12b250

SomePersonFromMars force-pushed the fix/ios-recording-interrupted branch from 534c3c0 to 3bd07bf Compare September 2, 2026 12:06

feat: document resuming recording after an interruption

86a9ae7

SomePersonFromMars force-pushed the fix/ios-recording-interrupted branch from 3bd07bf to 86a9ae7 Compare September 2, 2026 12:09

SomePersonFromMars added 3 commits September 2, 2026 15:48

fix: detach source node in player on failed start similarly to what r…

673d326

…ecorder does

fix: don't poison state on a no-op deactivation

d648901

fix: recorder resume() only updates state on successful engine start

33c3753

SomePersonFromMars requested review from closetcaiman and maciejmakowski2003 and removed request for closetcaiman September 4, 2026 11:09

SomePersonFromMars marked this pull request as ready for review September 4, 2026 11:09

SomePersonFromMars requested a review from closetcaiman September 4, 2026 11:09

SomePersonFromMars changed the title ~~Fix/ios recording interrupted~~ fix(ios): recording resume after an interruption Sep 4, 2026

maciejmakowski2003 requested changes Sep 4, 2026

View reviewed changes

maciejmakowski2003 reviewed Sep 4, 2026

View reviewed changes

SomePersonFromMars added research Information gathering, technical analysis, or feasibility studies fix Code changes specifically addressing and resolving a bug ios Native iOS implementation, CoreAudio/AVFoundation bindings, or iOS-specific issues labels Sep 7, 2026

github-actions Bot added the conflicts This PR has conflicts with the base branch. label Sep 11, 2026

Merge branch 'main' into fix/ios-recording-interrupted

bcadbb3

github-actions Bot removed the conflicts This PR has conflicts with the base branch. label Sep 17, 2026

SomePersonFromMars added 3 commits September 17, 2026 16:30

Merge branch 'main' into fix/ios-recording-interrupted

32c2906

fix: workaround to mitigate infinite loop when starting recording

6b17b0f

fix: schedule rebuild on configuration change instead of doing it int…

d9268b3

…errupted state

github-actions Bot added the conflicts This PR has conflicts with the base branch. label Sep 22, 2026

Merge branch 'main' into fix/ios-recording-interrupted

3249d2d

github-actions Bot added conflicts This PR has conflicts with the base branch. and removed conflicts This PR has conflicts with the base branch. labels Sep 22, 2026

closetcaiman added this pull request to stack #1318 September 24, 2026 17:02

Merge branch 'main' into fix/ios-recording-interrupted and verified o…

41dbdd5

…n device that it still works.

github-actions Bot removed the conflicts This PR has conflicts with the base branch. label Sep 28, 2026

SomePersonFromMars and others added 3 commits September 29, 2026 11:45

fix: explicitely expressed logic of playback and recording resume

c4601b4

fix: cache the intended shouldResume value for retry

f5c49c4

fix: wording in apps/CLAUDE.md

a6acc6b

Co-authored-by: Maciej Makowski <maciej.makowski2608@gmail.com>

SomePersonFromMars requested a review from maciejmakowski2003 September 29, 2026 11:02

Merge branch 'main' into fix/ios-recording-interrupted

02f7a69

SomePersonFromMars requested review from mdydek and a balanced review from Copilot October 1, 2026 15:20

This comment was marked as spam.

Sign in to view

fix: broken relative audiodocs links

3c491fc

mdydek requested changes Oct 1, 2026

View reviewed changes

github-actions Bot added the conflicts This PR has conflicts with the base branch. label Oct 2, 2026

style: cleanups

ba9e6b5

	Allows the app to play audio in the background on iOS. Corresponds to adding `audio` to [`UIBackgroundModes`](https://developer.apple.com/documentation/bundleresources/information-property-list/uibackgroundmodes).
	Allows the app to play audio in the background on iOS.


		An interruption is the system taking the audio session away due to a phone call, an alarm, or another non-mixable audio session. It deactivates the session and stops the I/O unit. Audio playback and capture therefore stop.

		A resume that completes while the app is still backgrounded is possible only when all of the conditions below hold.

Conversation

SomePersonFromMars commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Breaking changes ⚠️

Introduced changes

Responds to the issue

Additional useful tweaks and fixes

Docs

Manual tests and reproductions used while debugging

Checklist

Uh oh!

maciejmakowski2003 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SomePersonFromMars Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SomePersonFromMars Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

WPT non-regression comparison

Uh oh!

SomePersonFromMars commented Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as spam.

Uh oh!

mdydek left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

SomePersonFromMars commented Aug 28, 2026 •

edited

Loading

SomePersonFromMars Sep 29, 2026 •

edited

Loading

SomePersonFromMars Sep 22, 2026 •

edited

Loading

github-actions Bot commented Sep 17, 2026 •

edited

Loading

SomePersonFromMars commented Sep 29, 2026 •

edited

Loading