feat: add delayed relay error handling and integrate with chat list s…

[codeswot]

…creen

Description

Optimize Relay Error Message Banner
Display

Summary

Improved the relay connection error
banner UX by adding intelligent delay
logic and automatic updates, making it
less aggressive while maintaining
important connectivity feedback.

Changes Made

1. Added Delayed Display Logic

• Created DelayedRelayErrorProvider that
  implements a 30-second delay before
  showing the error banner
• Prevents banner from appearing during
  temporary connection hiccups
• Immediately dismisses banner when
  connection is restored, canceling any
  pending delay

2. Enhanced User Experience

• Updated ChatListScreen to use the new
  delayed banner logic
• Banner now only appears for persistent
  connection issues (30+ seconds)
• Real-time dismissal when relays
  reconnect - no more manual refresh
  needed
• Maintains real-time connection
  checking for "New Chat" button
  functionality

3. Integrated with Polling System

• Added relay status checking to the
  existing polling infrastructure
• Automatic updates every 2 seconds
  ensure banner state stays current
• No manual refresh required to detect
  connection changes

4. Improved Dark Mode Skeleton Loaders

• Updated gray100 and gray200 colors in
  dark theme for better contrast
• Changed from light grays (#F5F5F5,
  #E5E5E5) to appropriate dark grays
  (#404040, #2A2A2A)

Technical Details

• New provider follows Riverpod patterns
  with proper state management
• Timer-based delay implementation with
  automatic cleanup
• Maintains backward compatibility with
  existing relay status checking
• Proper error handling for edge cases
  (loading states, connection errors)

Impact

• Reduces user frustration from
  premature error notifications
• Provides immediate feedback when
  connectivity is restored
• Better visual hierarchy in dark mode
  skeleton states
• Maintains app reliability indicators
  without being overly aggressive

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore
• 🧪 Tests

Checklist

• Run just precommit to ensure that formatting and linting are correct
• Run just check-flutter-coverage to ensure that flutter coverage rules are passing
• Updated the CHANGELOG.md file with your changes (if they affect the user experience)

Summary by CodeRabbit

• New Features
  • Adds an intelligent relay error banner with a 30-second delay; auto-dismisses on reconnection.
  • Disables “New Chat” and updates its icon/opacity while the banner is shown.
  • Polling now refreshes relay statuses on startup and during ongoing checks for more accurate connection state.
• Style
  • Adjusts dark theme grays: gray100 and gray200 updated for improved contrast.
• Documentation
  • Changelog updated to note the delayed relay error banner behavior.

[coderabbitai]

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title succinctly summarizes the primary change—adding delayed relay error handling and integrating it with the chat list—and aligns with the PR objectives and modified files; it is concise and focused on the main behavior change.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 667-network-relay-error-message-too-aggressive

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 99b6aa4 and 9d4d03b.

📒 Files selected for processing (6)

• CHANGELOG.md (1 hunks)
• lib/config/providers/delayed_relay_error_provider.dart (1 hunks)
• lib/config/providers/polling_provider.dart (3 hunks)
• lib/config/providers/relay_status_provider.dart (0 hunks)
• lib/ui/contact_list/chat_list_screen.dart (5 hunks)
• lib/ui/core/themes/src/colors_dark.dart (1 hunks)

💤 Files with no reviewable changes (1)

• lib/config/providers/relay_status_provider.dart

🧰 Additional context used

📓 Path-based instructions (2)

**/*.dart

📄 CodeRabbit inference engine (.cursor/rules/flutter.mdc)

**/*.dart: Always declare the type of each variable and function (parameters and return value). Avoid using 'any'. Create necessary types.
Don't leave blank lines within a function.
One export per file.
Use PascalCase for classes.
Use camelCase for variables, functions, and methods.
Use underscores_case for file and directory names.
Use UPPERCASE for environment variables. Avoid magic numbers and define constants.
Start each function with a verb.
Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.
Use complete words instead of abbreviations and correct spelling, except for standard and well-known abbreviations (API, URL, i, j, err, ctx, req, res, next).
Write short functions with a single purpose. Less than 20 instructions.
Name functions with a verb and something else. If it returns a boolean, use isX or hasX, canX, etc. If it doesn't return anything, use executeX or saveX, etc.
Avoid nesting blocks by early checks and returns, or extraction to utility functions.
Use higher-order functions (map, filter, reduce, etc.) to avoid function nesting. Use arrow functions for simple functions (less than 3 instructions). Use named functions for non-simple functions.
Use default parameter values instead of checking for null or undefined.
Reduce function parameters using RO-RO: use an object to pass multiple parameters and to return results. Declare necessary types for input arguments and output.
Use a single level of abstraction in functions.
Don't abuse primitive types and encapsulate data in composite types.
Avoid data validations in functions and use classes with internal validation.
Prefer immutability for data. Use readonly for data that doesn't change. Use 'as const' for literals that don't change.
Declare interfaces to define contracts.
Write small classes with a single purpose. Less than 200 instructions, less than 10 public methods, less than 10 properties.
Use exceptions to handle errors you don't expect. If you catch an exception, it sh...

Files:

• lib/config/providers/delayed_relay_error_provider.dart
• lib/ui/core/themes/src/colors_dark.dart
• lib/config/providers/polling_provider.dart
• lib/ui/contact_list/chat_list_screen.dart

**/*.md

📄 CodeRabbit inference engine (.cursor/rules/whitenoise.mdc)

**/*.md: NIPs (Nostr Implementation Possibilities) are numbered like NIP-XX where XX are two capitalized hexadecimal digits, e.g., NIP-01 and NIP-C7.
To read a specific NIP, construct the NIP URL following this template: https://raw.githubusercontent.com/nostr-protocol/nips/refs/heads/master/{nip}.md (replace {nip} in the URL template with the relevant NIP name, e.g., 07 for NIP-07, or C7 for NIP-C7).
To read the definition of a specific kind, construct a URL following this template: https://nostrbook.dev/kinds/{kind}.md (replace {kind} in the template with the kind number, e.g., https://nostrbook.dev/kinds/0.md for kind 0).

Files:

• CHANGELOG.md

🧠 Learnings (2)

📚 Learning: 2025-09-08T17:39:13.711Z

Learnt from: josefinalliende
PR: parres-hq/whitenoise_flutter#599
File: test/ui/contact_list/start_chat_bottom_sheet_test.dart:173-176
Timestamp: 2025-09-08T17:39:13.711Z
Learning: In the whitenoise Flutter app, the followProvider uses followsProvider behind the scenes, so mocking followsProvider with MockFollowsNotifier effectively controls what followProvider sees in tests.

Applied to files:

• lib/config/providers/polling_provider.dart

📚 Learning: 2025-09-07T02:15:31.931Z

Learnt from: josefinalliende
PR: parres-hq/whitenoise_flutter#594
File: lib/src/rust/api/utils.dart:12-16
Timestamp: 2025-09-07T02:15:31.931Z
Learning: The lingering PublicKey references in lib/config/providers/auth_provider.dart, lib/config/providers/group_provider.dart, and rust_builder/cargokit/build_tool/lib/src/options.dart identified during the utils.dart API cleanup were fixed in PR #597 in the whitenoise_flutter codebase.

Applied to files:

• lib/config/providers/polling_provider.dart

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Flutter CI

🔇 Additional comments (18)

CHANGELOG.md (1)

22-22: LGTM! Well-documented feature addition.

The changelog entry clearly describes the relay connection error banner optimization with intelligent delay and immediate dismissal functionality.

lib/config/providers/polling_provider.dart (3)

8-8: LGTM! Proper integration of relay status refreshing.

Adding the relay status provider import enables the polling system to keep relay connection status current.

---

80-80: LGTM! Ensures relay status is refreshed during initial load.

Adding refreshStatuses() to the initial data load ensures relay connection status is updated when the app starts.

---

120-122: LGTM! Regular relay status updates during polling.

Adding relay status checks to incremental polling ensures the UI stays current with relay connectivity changes every 2 seconds.

lib/ui/contact_list/chat_list_screen.dart (6)

10-10: LGTM! Proper import for delayed relay error functionality.

Adding the delayed relay error provider import enables the screen to use the new 30-second delayed banner logic.

---

293-294: LGTM! Clean integration with delayed relay error provider.

The code properly watches the delayed relay error provider and extracts the shouldShowBanner flag for UI control.

---

318-325: LGTM! Proper UI state management for New Chat button.

The button is correctly disabled when relay errors should be shown, preventing users from attempting to create chats when relays are disconnected.

---

326-332: LGTM! Visual feedback for disabled state.

The icon and opacity changes provide clear visual feedback when the New Chat functionality is disabled due to relay connection issues.

---

339-342: LGTM! Consistent spacing for error banner.

Adding consistent spacing when the relay error banner is shown maintains proper UI layout.

---

458-480: LGTM! Informative error banner with clear action.

The banner provides clear messaging about the relay connection issue and offers a direct path to resolve it through the network settings.

lib/config/providers/delayed_relay_error_provider.dart (7)

8-26: LGTM! Well-structured state class with proper immutability.

The DelayedRelayErrorState class follows Dart best practices with immutable properties and a proper copyWith method implementation.

---

28-34: LGTM! Appropriate configuration and initialization.

The 30-second delay duration aligns with the PR objectives, and the notifier properly tracks connection status with logging support.

---

35-51: LGTM! Proper provider listening and error handling.

The build method correctly sets up listening to the relay connection provider and handles all async states appropriately (data, loading, error).

---

53-66: LGTM! Smart connection state change logic.

The connection status change handling correctly:

• Immediately hides banner on reconnection
• Starts delay timer on disconnection
• Tracks previous state to avoid unnecessary operations

---

68-93: LGTM! Robust delay timer implementation.

The delay timer logic properly:

• Cancels existing timers before starting new ones
• Re-checks connection status after delay expires
• Handles all async states during the final check
• Provides comprehensive logging for debugging

---

95-106: LGTM! Proper resource cleanup.

Both _cancelDelayTimer and dispose methods ensure timers are properly cancelled to prevent memory leaks.

---

108-111: LGTM! Standard Riverpod provider declaration.

The provider is properly declared following Riverpod patterns and naming conventions.

lib/ui/core/themes/src/colors_dark.dart (1)

28-29: Incorrect — brightness order not reversed; skeleton uses gray100 as base and gray200 as highlight

• Verified: DarkAppColors.gray100 = #404040, gray200 = #2A2A2A (lib/ui/core/themes/src/colors_dark.dart:28-29). wn_skeleton_container defaults: baseColor = context.colors.gray100, highlightColor = context.colors.gray200 (lib/ui/core/ui/wn_skeleton_container.dart:80-81).
• Conclusion: The original claim that "gray100 is now darker than gray200" is incorrect (gray100 remains lighter). However, the skeleton currently sets the highlight darker than the base — confirm intended visual and either swap base/highlight in wn_skeleton_container or adjust the dark theme gray values.

Likely an incorrect or invalid review comment.

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[erskingardner]

Just to make sure I'm understanding this:

1. Any time we get a change in connection status, this _handleConnectionStatusChange method is called.
2. If we're entering a not connected state then we show the banner and start the timer to check in 30 seconds.
3. If we're entering a connected state then we hide the banner and cancel the timer?

How we we hear about these changes in connection status?

[codeswot]

if we enter a not connected state we delay for 30 seconds, and if after that 30 seconds connection is not back we show the banner

[Quwaysim]

LFGTM 🚀