メインコンテンツへスキップ

FANSHIP int32 桁溢れに対する説明と調査のお願い

  • 更新

いつも FANSHIP をご利用いただきありがとうございます。

先日ご案内させていただいた「プッシュ配信の配信IDについてのお知らせ」についての続報です。

プッシュ配信時に自動発番される配信IDが 7/25 10:00 時点で  2,107,634,051 を超えており、
32 bit のInteger型（以下、Int型）の最大値（2,147,483,647）を、8/30頃 ※ に超える見込みとなっています。
※ あくまで実績ベースとなり、2, 3日の前後が考えられます。

 

影響調査の進捗

サーバーサイド

  • データベース等への影響およびプログラムへの影響調査：完了
  • 画面表示周りへの影響調査：7/26（火）完了予定
  • 桁あふれ延命対応：8/1（月）実施

SDK

  • エンジニアによる影響調査：完了
  • 回帰テストによる影響調査：iOS 7/27（水）完了予定、Android 7/28（木）完了予定

 

影響範囲

影響範囲と、FANSHIPで実施予定の対策

mceclip0.png

 

① iOS SDK の一部処理への影響

FANSHIPの配信IDにおいて、Int型の最大値（2,147,483,647）超過後に関しては、以下に関連するカスタマイズを実施していた場合に影響が発生する場合がございます。 


■ お知らせ一覧／詳細画面において配信IDを用いたプログラムの改修やデータ連携などを独自にカスタマイズしていた場合

※SDK内で保持している配信IDにおいて、マイナス値で扱われることで以下の影響が考えられる

カスタマイズを実施しており、かつカスタマイズにより、配信IDがマイナスで扱われることによる不都合が出るような改修がなければ影響はございません。

 

以下のような例では不具合が発生する場合があります。

例：

  • 配信ID がマイナスの場合は、後続の処理をしないような分岐が入っている
  • 配信ID 順に表示を並び替えている
  • 配信ID を中間サーバーなどに送信している

 

確認方法

  • 「piId」「messageId」で検索

mceclip2.png


基本的には、 PopinfoListViewController がお知らせ一覧、PopinfoDetailViewController がお知らせ詳細になります。クラスを継承している場合などは他にも処理が入っている可能性はあります。
FANSHIP SDK では、「piId もしくは messageId」という物理名で扱っていますので上記のContollerで、前述で例示したような処理が入っていないか、ご確認ください。

 

■ 以下に関連するカスタマイズを実施していた場合

SDK内で保持している配信IDにおいて、マイナス値で扱われることで以下の影響が考えられます。

  • SDKが提供するお知らせに関するコールバック関数を利用している場合
    → マイナスの値の配信IDが連携されたり、通常とは異なるコールバック関数が呼び出される可能性がございます。

 具体的には、以下のコールバックをご利用の場合になります。

（1）PopinfoReceiverDelegate の popinfoReceiver:didReceivePopinfoMessage:category:result:

・デリゲートがコールされない
・届いたお知らせのカテゴリに応じて、表示するお知らせ一覧を動的に変えたい場合に動作しない
　組み込みガイド：https://docs.fanship.jp/ios-sdk-instruction-guide/standard-801/customize/info-list.html#_3
・実装次第にはなりますが、アプリが起動するだけなどになる可能性が高いです

mceclip5.png


（2）PopinfoReceiverDelegate の popinfoReceiver:updateMessagesResult:

・通常のコール条件と異なり、（１）の代わりに当該デリゲートがコールされてしまう

mceclip6.png


(3) PopinfoReceiverクラスの updateMessagesメソッドのコールバックを利用しており、そこで渡される messages 配列の message オブジェクトの piId を参照する処理を独自に追加している場合

mceclip7.png


カスタマイズを実施しており、かつカスタマイズにより、配信IDがマイナスで扱われることによる不都合が出るような改修がなければ影響はございません。

 

② お客様独自のデータベースなどで配信IDを利用している場合

中間サーバーからManagement API経由で配信を実行しているようなシステムや、
配信の分析の為に配信IDを取得・保持しているようなシステムで、以下の影響が考えられます。

  • 配信IDをDBに保持しており、型をInt型で設定している場合
  • プログラムで、配信IDを明示的にInt型として扱っている場合

⇒ 上記の場合、配信IDがInt型の最大値（2,147,483,647）を超えた場合、桁あふれのエラーを起こすことが想定されます。

 

お客様独自のデータベースなどで配信IDを保存していない場合、もしくは Int型の最大値以上の受付が考慮されている場合（Int unsigned型やBigInt型が使われている場合）においては影響はございません。

 

③ レポート（カスタムイベント）

＜イベントトラッキング機能＞

  • カスタムイベントに桁あふれによってマイナス値となった配信IDを含めた状態で、FANSHIPサーバに送信した場合に以下の事象が発生します
  • 外部データ連携機能にて連携されたデータ内に、マイナス値となった配信IDが含まれたカスタムイベントが連携されます。（連携されたデータを元に、お客様側で分析を行った際に、マイナス値となった配信IDが含まれているため分析側で影響がある可能性が考えられます）

 

＜Webview版イベントトラッキング機能＞

  • カスタムイベントに桁あふれによってマイナス値となった配信IDを含めた状態で、FANSHIPサーバに送信した場合
  • 外部データ連携機能にて連携されたデータ内に、マイナス値となった配信IDが含まれたカスタムイベントが連携されます。（連携されたデータを元に、お客様側で分析を行った際に、マイナス値となった配信IDが含まれているため分析側で影響がある可能性が考えられます）

  • 独自にイベントを設定していない場合、カスタムイベントでも値に配信IDを連携していない場合においては影響ございません。
  • 事前に配信IDを連携しているカスタムイベント情報をご連絡いただければ、対応いたします。
    一定期間マイナス値が許容されるケースにおいては、SDKの改修をお待ちください。

 

対策スケジュール予定について

  • 8/1（月）延命策対応の実施 2022/8/01 11:50 更新
  • 8/4（木）サーバーサイドの改修リリース
  • 8/5（金）SDK の改修リリース 2022/7/29 13:30 更新
  • int32桁溢れ予想日は こちらの記事  をご確認ください


お手数ですが、アプリ側で致命的な影響がないか調査いただき、影響がある場合はSDKの差し替えやサーバー側の対策を実施いただけますようお願い申し上げます。

int32の桁あふれの再現テストが実施出来る環境は準備出来ますので、必要なお客様はお問い合わせください。


以上でございます。
何卒よろしくお願い申し上げます。

関連記事