Mobile invite sheet: Join retry silently no-ops after claim error

[tlongwell-block]

Summary

After a claim error in the mobile invite join sheet, the error UI re-enables Join, but tapping it silently does nothing.

Root cause

invite_join_sheet.dart allows the button in the error state, while the provider's confirmJoin() returns early unless status is confirming.

Expected behavior

A retry should either:

• allow confirmJoin() from both confirming and error, or
• keep Join disabled and provide an explicit reset/retry path.

Found during the independent review of PR #1957; non-blocking for that PR but should be fixed as a fast-follow.

[BradGroux]

This appears to be stale: current main already implements the expected retry path.

• confirmJoin() permits both InviteJoinStatus.confirming and InviteJoinStatus.error, while still rejecting expired invites:

  buzz/mobile/lib/features/invites/invite_join_provider.dart

  Lines 94 to 101 in 7e34bee

  	Future<void> confirmJoin() async {
  	final invite = state.invite;
  	if (invite == null ||
  	state.requiresFreshInvite ||
  	(state.status != InviteJoinStatus.confirming &&
  	state.status != InviteJoinStatus.error)) {
  	return;
  	}

• There is a focused regression test, failed claim can be retried and preserves policy receipt, which makes the first claim return 503, retries, and asserts success plus two attempts:

  buzz/mobile/test/features/invites/invite_join_provider_test.dart

  Lines 186 to 239 in 7e34bee

  	test('failed claim can be retried and preserves policy receipt', () async {
  	final keys = nostr.Keys.generate();
  	var attempts = 0;
  	final bodies = <String>[];
  	final storage = CommunityStorage(secure: FakeSecureStorage());
  	final auth = _RecordingAuthNotifier();
  	final container = ProviderContainer(
  	overrides: [
  	communityStorageProvider.overrideWithValue(storage),
  	authProvider.overrideWith(() => auth),
  	inviteKeyGeneratorProvider.overrideWithValue(() => keys),
  	inviteJoinHttpClientProvider.overrideWithValue(
  	http_testing.MockClient((request) async {
  	attempts++;
  	bodies.add(request.body);
  	if (attempts == 1) {
  	return http.Response(jsonEncode({'error': 'temporary'}), 503);
  	}
  	return http.Response(
  	jsonEncode({
  	'status': 'joined',
  	'host': 'relay.example.com',
  	'role': 'member',
  	}),
  	200,
  	);
  	}),
  	),
  	],
  	);
  	addTearDown(container.dispose);
  	await container
  	.read(inviteJoinProvider.notifier)
  	.prepare(
  	const InviteDeepLink(
  	relayUrl: 'wss://relay.example.com',
  	code: 'code',
  	policyReceipt: 'receipt.value',
  	),
  	);
  	await container.read(inviteJoinProvider.notifier).confirmJoin();
  	expect(container.read(inviteJoinProvider).status, InviteJoinStatus.error);
  	await container.read(inviteJoinProvider.notifier).confirmJoin();
  	expect(container.read(inviteJoinProvider).status, InviteJoinStatus.success);
  	expect(attempts, 2);
  	expect(
  	bodies,
  	everyElement(
  	jsonEncode({'code': 'code', 'policy_receipt': 'receipt.value'}),
  	),
  	);

• Both were included when feat: add invite QR and mobile direct join #1957 merged in commit 648cbf3: 648cbf3

I attempted the focused Flutter test during an open-issue audit, but the repo's pinned toolchain bootstrap did not finish within the bounded check, so I am not claiming a fresh runtime pass here. The source and regression coverage do show that the reported early-return condition is no longer present.

Suggested maintainer action: close as already fixed. If this still reproduces in a current release, it likely represents a different path; a Buzz version and fresh trace would help distinguish it.

[mdmohsin7]

Ran that test on 7e34bee, all 5 pass including the retry one. Needed . ./bin/activate-hermit first, might be what got you on the bootstrap. Looks closeable.