Skip to content
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion lib/utils/services/tb_client_service/tb_client_service.dart
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,9 @@ class TbClientService implements ITbClientService {

return;
}
_overlayService.showErrorNotification((_) => e.message!);
_overlayService.showErrorNotification(
(context) => e.message ?? S.of(context).unknownError,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fallback itself is right. Two thoughts while here:

This is now the fourth copy of e.message ?? S.of(context).unknownError_getMessage just above (line 60), Error._getMessage in error_provider.dart:28, and the nested getMessage in TbContext.onFatalError (tb_context.dart:123). Meanwhile error_provider.dart:22 and tb_context.dart:142 still force-unwrap tbError.message! — the exact crash this PR fixes. Would it be worth a tiny extension next to the other translation helpers, e.g. in lib/utils/translation_utils.dart:

extension ThingsboardErrorTranslation on ThingsboardError {
  String translatedMessage(BuildContext context) =>
      message ?? S.of(context).unknownError;
}

Then this becomes (context) => e.translatedMessage(context), _getMessage shrinks to the fatalApplicationErrorOccurred prefix plus that call, and the two remaining ! sites get a drop-in replacement instead of waiting for the same crash report from whichever path is still live. It also gives you something cheap to cover with a testWidgets that pumps a MaterialApp with S.delegate and asserts both branches — there's no test for the new behavior right now (and no test/ dir at all), and since the bug was precisely a null-handling assumption, pinning it seems worth a few lines.

On UX: the user now gets a 2-second toast saying "Unknown error." with nothing to act on or quote to support. Since we only land here when the client gave no message, errorCode/status are usually still populated — folding a short code into the toast (there's already an errorOccured: "Error occured: {e}" string of that shape) tends to pay for itself in support triage. Fine to leave as-is for the crash fix; just flagging the trade-off.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in f6a8885.

  • Added ThingsboardErrorTranslation.translatedMessage(context) in lib/utils/translation_utils.dart.
  • All four message ?? unknownError copies now go through it (_getMessage here, Error._getMessage, the nested getMessage in TbContext.onFatalError, and this toast).
  • Replaced the two remaining tbError.message! force-unwraps in Error.onError and TbContext.onError with the same call.

Skipped the widget test: the project has no test/ directory, so adding one for this alone is out of scope for this PR. Left the toast text as-is; folding in errorCode/status needs a new localized string, so I'd take that as a follow-up.

);
});
}

Expand Down