cloud storageへfile.saveをしようとしたらTypeError: RequestInit: duplex option is required when sending a body.

こんな感じのコードでfirebase adminをつかってバイナリファイルをcloud storageへアップロードしようとした。

const bucket = admin
  .storage()
  .bucket("hogehoge");

const bufferedContent = Buffer.from(base64EncodedContent, "base64");

const filePath = `${userId}/${base64EncodedContent.name}`;
const file = bucket.file(filePath);
await file.save(bufferedContent, {
  resumable: true,
  metadata: { contentType: base64EncodedContent.contentType },
});

が、実行するとTypeError: RequestInit: duplex option is required when sending a body.というエラーになってしまった。 見たことないエラーだし、chatGPTに聞いても検索しても何もわからず。。。

その他の雑多なエラーメッセージを見ていたところ /node_modules/@google-cloud/storage/build/src/resumable-upload.js:641:21 /node_modules/@google-cloud/storage/build/src/resumable-upload.js:497:26 でエラーが発生しているらしく、resumable-upload周りがおかしいんじゃないの？と思い、 resumable: false にしてみたら無事エラー解消。

とりあえず動くようになってよかったが、何が問題だったのかはわからない。。。

アップロード対象のサイズが極小過ぎて（45byteのテキストファイル）、いい感じに分割してアップロードしようとする処理がエラーになったとかそういう感じなのかな。

postmarkのinbound rules apiでハマったのでメモ

Inbound rules triggers API | Postmark Developer Documentation

postmarkのinbound rules api（受信拒否アドレス、ドメインを設定するapi）にpostでルール追加しようとしたら、エラーになった。

ErrorCodeは101らしいが、公式のエラーコードのドキュメントに101なんて記載はない。

リクエスト内容をよくよく確認したら、すでに追加済みのruleを新規にpostしており、既存のruleをpostしたことによるエラー＝エラーコード101ということらしい

こちらとしてはユーザーにそのままエラーを伝えずに既存ルールの重複であることを伝えてあげたいので、

    } catch (error) {
      // エラーコード101の場合は恐らく重複のため、isDuplicatedを返す
      if (error.response.data.ErrorCode === 101) {
        return res.status(200).send({ isDuplicated: true });
      }
      ...

こんな風にエラー時にエラーコードが101だったら重複フラグをつけてレスポンスを返すことにした。

postmarkのservers apiが422エラーになってハマったのでメモ

sendgridが大嫌いなのでメール配信サービスはpostmarkを使っている。

postmarkで新規サーバーを作成する処理をつくったら、謎にエラーになったのでメモ。

Servers API | Postmark Developer Documentation

このAPIに対してPOSTでリクエストしたらエラーになった。 エラーには Request failed with status code 422 という情報しか含まれておらず手詰まり。

リクエストの仕方が悪いのかと思って試しにpostmanからリクエストしてみたところ、エラーは相変わらず422だが、

{
    "ErrorCode": 602,
    "Message": "This inbound domain is already in use on another server in Postmark."
}

というdataが返ってきていることがわかった。

原因はbody.InboundDomainに指定したドメインがすでに別サーバーで使用されているとのこと。

言われてみれば確かに、既存のサーバーにて *.inbound.test.com をInboundDomainに設定してある状態で、 新規サーバーの作成時に

{ "InboundDomain": "sandbox.inbound.test.com"}

という値をリクエストしていた。

明示的なサブドメイン指定＞ワイルドカードのサブドメイン指定という扱いにはならないらしい。

既存サーバーの設定値を変更したら無事にリクエストが通るようになったので解決。

firebase emulators:export ./をしたら全てがrmされた

まじで意味がわからないんだけどとりあえずemulatorのファイルを出力してみようと雑に firebase emulators:export ./ をしたら、全てのファイルがrmされた。

export先のディレクトリをまずrmdir -fするらしい。

remoteにpushしてなかった10時間分の作業内容が消えたし、rmだから復元できないし、envとかも失われてるからもっかい用意しないといけないし、まじでだるい。。。

こんな危険な挙動を野放しにしないでほしい。

cloud functionsで参照型の値を含むobjectを扱おうとしたらUncaught RangeError: Maximum call stack size exceeded

cloud functions経由でfirestoreからデータ取得する処理がなんかInternal errorになったのでメモ。

{
  name: "hogehoge",
  email: "aaaa@example.com"
}

こんな感じのuserDoc的を返す処理で昨日までは普通に動いてたんだけど、

{
  name: "hogehoge",
  email: "aaaa@example.com",
  teamRef: db.collection("teams").doc("hoge"),
}

こんな感じでreference typeなフィールドを追加するようにしたら動かなくなってしまった。 refの中身がガチでありのまま扱われてしまって処理しきれん的な感じだろう。

groups.google.com

firebase便利だけどrefの扱い方に関するドキュメントが少なすぎてほんとよろしくない。

回避策としてはこのスレにあるようにJSON.parse(JSON.stringify())するしかなさげ？

react18でreact-jsonschema-formつかったらconsoleにwarning出っぱなし

Warning: Using UNSAFE_componentWillReceiveProps in strict mode is not recommended and may indicate bugs in your code. See https://reactjs.org/link/unsafe-component-lifecycles for details.

コンソールにこういうwarningが出てる。

react16.9からcomponentWillReceivePropsが非推奨になったんだけど、react-jsonschema-formではまだそれに対応できていないらしい。

github.com

2022/9/3時点ではgithubでも報告されてるけどまだ対応されてなさそうだから、現状はwarning無視しておくしかない。

CloudBuildで”no concurrent builds quota available to create builds”エラー

GitHubにプッシュ→CloudBuild→CloudRunへデプロイという感じで動いていたプロジェクトで、CloudBuildが急にエラーというか失敗するようになった。

ログを見ると、

ビルドを実行できませんでした: generic::failed_precondition: generic::failed_precondition: no concurrent builds quota available to create builds という内容が表示されていた。

no concurrent builds quota available to create buildsを日本語に訳すとビルドの作成に使用できる同時ビルドクォータがないということ。 ざっくりとは、ビルド実行するリソースがないらしい。なら失敗じゃなくてキューを待機させてくれればいいのに。

この件について英語のサイトでいろいろな報告を読んだが、 ・ユーザー側で何かコントールできることはない（プライベートプール的なリソースを有料課金しない限りどうにもできないものらしい） ・リージョンをglobalにするとなんか解消するよ という情報しか得られなかった。

なんとなくCloud Runのリージョンをasia-northeast1にしてるから、Cloud Buildのトリガーもasia-northeast1にしてたんだけど、とりあえずアドバイスに沿ってトリガーのリージョンをglobalにしてみたら、本当に解決した。

globalにしておくと世界中のリージョンからリソースをよしなに活用してくれるってことなのかな。 それにしても深夜２時にasia-northeast1でリソースが少なくなるっておかしい気がするけども。腑に落ちないけど解決。