[Bug]: Generic "Error: 1" in Sentry
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 32/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- ios, react-native, typescript
- 領域
- mobile
調査の方向性
Start with the promise behavior of BackgroundFetch.configure on iOS, as the reporter describes it, and compare it with the documented return values of 0, 1 and 2. Decide whether configure should resolve with the status or reject, and settle that with maintainers before writing code. Done means the chosen behavior is documented and a test or sample shows the rejected case is caught.
索引モデルが issue の本文から書いたものです。
説明
Required Reading
- Confirmed
Plugin Version
4.4.2
Mobile operating-system(s)
- iOS
- Android
Device Manufacturer(s) and Model(s)
any iOS device (SE, 15, 17)
Device operating-systems(s)
iOS 26 + 13% other
React Native / Expo version
RN86
What happened?
6 years of "Error: 1" in Sentry. Never dug into it - till now w/ AI.
Long story short. We followed doc sample, but best I understand iOS devices will only ever return status=2 from that await as anything else is rejected in the promise and not caught.
So it explains why our Sentry filled over 6 years with these rare, but impossible to triage errors since its a bare rejection from native with no stacktrace.
We adapted to this
try {
await BackgroundFetch.configure(...)
} catch {
// Status is read below
}
try {
const status = await BackgroundFetch.status()
// etc
Wouldn't it be cool since the docs suggest reading the status from .configure that it could return 0,1 or 2? Or should it never do that and instead reject and we handle in userland? Just seems like we stumbled upon the source of the error, but don't have best idea on fix and we were just following doc recommendation.
Plugin Code and/or Config
let status = await BackgroundFetch.configure({
minimumFetchInterval: minimumFetchInterval,
stopOnTerminate: false,
startOnBoot: true,
requiredNetworkType: BackgroundFetch.NETWORK_TYPE_ANY,
requiresBatteryNotLow: true,
}, async (taskId) => {
BackgroundFetchCallBack();
BackgroundFetch.finish(taskId);
}, async (taskId) => {
BackgroundFetch.finish(taskId);
});
Relevant log output
- 主要言語
- Java
- スター
- 1.6k
- フォーク
- 194
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
transistorsoft/react-native-background-fetch のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
transistorsoft/react-native-background-fetch#583 · コメント 1 件 ·
transistorsoft/react-native-background-fetch の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
NationalSecurityAgency/ghidra#10220 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
メンテナーはふだん 1 日以内に返信
-
RIS export splits an organization name containing “and” into multiple authors対応中かも @Gautam-aman が今日担当しました。 オープンstatus: needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
JabRef/jabref#17821 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
FailureContext.java rounds down thresholds in lastedAtLeast()対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信