DEV Community: cometa-kaito

Bing Webmaster UrlCount Stuck at 1: the sitemap-index Trap

cometa-kaito — Sun, 08 Nov 2026 02:22:45 +0000

Conclusion first

This blog (tech.rebounder.jp) publishes 3-4 posts a day. If it took search engines days to weeks to come crawl, anything written would just sit unread until they showed up. Two mechanisms close that gap: IndexNow, which tells Bing and Yandex "this changed" the instant it happens, and the Bing Webmaster API, which proactively registers the sitemap and individual URLs.

But "registered" and "verified" turned out not to mean "indexed." Bing treated this site as a single-page site for three days. The cause: only sitemap-index.xml — the table of contents for the sitemaps — had ever been submitted.

IndexNow alone isn't enough

IndexNow is a free protocol that only requires publishing one key file to instantly tell Bing, Yandex, and others "this URL changed." No account, no cost. tech.rebounder.jp pulls its recent changes from git log (which files were committed) and notifies on exactly the URLs whose Markdown actually diffed.

The catch: Google doesn't support it. IndexNow only speeds things up on the Bing/Yandex side; Google still has to discover pages the old way, through sitemaps and internal links. Since ChatGPT's search runs on Bing's index, IndexNow ends up mattering less for Google and more directly for LLM exposure.

Bing Webmaster counts UrlCount as 1 and stops

IndexNow is a notification, not a registration. For Bing to understand the site's overall structure, the sitemap still has to be registered separately through Bing Webmaster.

tech.rebounder.jp registered with Bing Webmaster on 2026-09-01 and showed IsVerified: true. But GetCrawlStats and GetQueryStats stayed empty, and impressions sat at zero.

The cause was that only sitemap-index.xml — the index file that just links out to the child sitemaps — had been registered. When Bing fetches that index through the API, it records UrlCount: 1 and stops there. The index file is itself just one XML file, so from Bing's side it looks like "a site with one URL registered." IsVerified: true only meant "we confirmed you own this site" — it never meant "we know what's on it."

The fix was to submit the child sitemaps (the ones that actually list article URLs, like sitemap-0.xml) directly via SubmitFeed. The moment that happened, UrlCount jumped from 1 to 203, and the site was crawled that same day. For three days, Bing had effectively believed this was a one-page site.

Day-to-day operation: register the sitemap and submit URLs, both

There's no need to redo everything from scratch each time. A script called push:bing automates two things:

Incremental sitemap registration — diffs the already-registered feed list (GetFeeds) against the child sitemap URLs listed in the post-build dist/sitemap-index.xml, and calls SubmitFeed only for the ones not yet registered.
Submitting recent URLs individually — builds URLs from Markdown files committed within git log --since=<N> days, and sends them with SubmitUrlbatch, checking Bing's daily quota (GetUrlSubmissionQuota) first so submissions don't exceed it.

The result gets checked against reality at the end. It re-fetches the feed list with GetFeeds and treats anything whose Status isn't Success as a failure. It also treats the total number of URLs Bing knows about as a failure if it's 1 or fewer — a guard against quietly treating 0 or 1 as a success, which is exactly the "only the index got through" state that caused the original problem. This is a mechanical check for the same failure mode that started it all.

A second trap: treating a rename as delete-plus-add

Both IndexNow and the Bing Webmaster API decide which URLs to submit by pulling "recently changed Markdown files" from git log --name-only. That command has a quirk: it reports a file rename as a delete-plus-add pair.

On the day an article slug actually got renamed, the old slug (which 404s in production) got swept into the submission batch right alongside the new one. One out of 15 URLs submitted that day pointed to something that didn't exist. Sending 404s doesn't just waste quota — it also erodes how much a search engine trusts the submission feed as a whole.

The fix was straightforward: keep only the paths from git log that actually exist in the working tree, checked with existsSync. "Was committed" and "currently exists" are different facts, and only the first one had been checked. The fix also logs how many files were dropped this way, so a silent reduction doesn't go unnoticed.

Cost

Both IndexNow and the Bing Webmaster API are free — no account fee, no monthly charge. URL submissions stay well within the daily quota of 100 and the monthly quota of 2,700, so tech.rebounder.jp's publishing pace (3-4 posts a day) runs with no billing risk at all. The only real cost is operational care: keeping the API key in .env.local and out of both build artifacts and the repository's public surface.

Summary

"Registered the site" and "confirmed as owner" turned out not to be the same thing as "the search engine knows what's on it." Bing Webmaster treated a table-of-contents file (sitemap-index.xml) as UrlCount: 1 and stayed there until the child sitemaps were submitted directly. On top of that, deciding which URLs to submit mechanically is fragile against an everyday operation like a rename. Both problems were only visible by checking the actual resulting numbers against the assumption that registering something means the search engine understood it.

Originally published at tech.rebounder.jp.

vercel inspect won't show which commit is live

cometa-kaito — Sat, 07 Nov 2026 02:24:19 +0000

Starting with the conclusion

When production is deployed straight from the Vercel CLI with vercel --prod instead of GitHub integration, the deployment is never linked to a git commit. If two people run vercel --prod at the same time, the later one silently overwrites the other — and checking vercel inspect afterward gives you no way to tell which build (and which commit) is actually live.

Symptom

On the morning of 2026-09-16, two separate pieces of work ran vercel --prod against the same Vercel project at the same time, colliding three times.

This project's deployment isn't triggered by a GitHub push integration — it's a local vercel --prod that uploads a build directly. That means every deploy reaches production instantly without anyone having to think about git state. The tradeoff: Vercel is never told which commit the build came from in the first place.

Running vercel inspect against the production deployment confirms this: the output lists the deployment ID, project name, state, creation time, the set of aliases, and the build artifacts — nothing resembling a git commit hash or commit message. This isn't a one-off rendering glitch from that incident; checking a CLI-uploaded deployment today still shows nothing about which commit it came from.

So when the two builds collided three times, there was no way afterward to look at vercel inspect and work out "which change is live right now." We couldn't even safely assume our own change had landed. The only way to re-establish certainty was to redeploy from the latest commit on the main branch, which meant two redeploys that shouldn't have been necessary.

Cause

The root cause: choosing a CLI-upload workflow instead of GitHub integration means the mechanism that ties a deployment to a git commit simply doesn't exist.

A GitHub-integrated deployment is built in response to a detected push, so Vercel can always record which commit it came from. A CLI upload, by contrast, is just a channel for sending a local build artifact — there's no standard way for it to tell Vercel which commit's working tree produced that artifact.

Because this project uses the CLI-upload workflow, Vercel had no material to distinguish between concurrent deploys from the start. Last-write-wins overwriting can happen with ordinary deployments too, but with GitHub integration the commit record lets you confirm which one is live now. With CLI upload, that information never existed, so there's no way to check it after the fact — that's the real difference.

Fix

To fix this without switching integration methods or touching the CLI workflow, we made no code change. Instead we wrote down an operational step: before running a deploy, confirm no other work is about to deploy at the same time.

Following that check on every deploy prevents the situation where two vercel --prod runs happen at once in the first place. Rather than trying to make vercel inspect distinguishable after the fact, we're preventing the collision before it happens.

Prevention

This incident caused no harm to production customers. Both of the colliding runs were from the same person (the same operator), so it resolved with two extra redeploys to re-establish certainty.

If you choose CLI-upload deployment over GitHub integration, you need to go in knowing that the assumption "I can check git state after deploying" does not hold. This isn't a Vercel bug — it's a capability that never existed once you picked that integration method, and it can't be solved by adding an after-the-fact check. The only real fix is eliminating the possibility of a concurrent run before it happens.

Originally published at tech.rebounder.jp.

PostgREST .or() Breaks Silently on a Comma

cometa-kaito — Fri, 06 Nov 2026 02:22:35 +0000

The short version

Interpolating a raw search term into a PostgREST .or() filter via a template literal breaks the filter grammar on a reserved character like a comma. On top of that, supabase-js doesn't throw on a transport or PostgREST failure — it represents it as a {data: null, error} return value — so the moment the caller reads .data ?? [], a broken filter that turns data into null gets treated as an empty array with no exception and no log. Global search's contacts query broke exactly this way. The fix was to split name and email into separate parameterized .ilike() calls and merge the results in JS.

The state it could become

The subject is global search in kimiteras-portal — the source behind both search and the command palette. It queries companies, contacts, projects, contracts, schools, tasks, and documents in one Promise.all round trip. Contacts alone need to match on both name and email, and before the fix it was written like this:

supabase
  .from("contacts")
  .select("id, name, email, company_id, school_id")
  .or(`name.ilike.${like},email.ilike.${like}`)
  .limit(5),

like is the search term formatted into %...%, and wildcard characters (%, _, \) were escaped. What wasn't escaped was the delimiter .or() itself uses: the comma. The result was handled the same way as every other category:

for (const c of contacts.data ?? [])
  hits.push({
    type: "Contact",
    label: c.email ? `${c.name} (${c.email})` : c.name,
    ...
  });

The first argument to .or() is a PostgREST-specific grammar string, name.ilike.<value>,email.ilike.<value>, where a comma is interpreted as a condition separator. If the search term itself contains a comma — someone typing a "Last, First" style name, or pasting a name straight off a business card — the generated string splits into extra conditions for every comma in it, and PostgREST can no longer parse it as a valid filter.

Why

What made this worse was how the failure surfaced. supabase-js query methods are designed not to reject their promise — a transport error and a PostgREST error response are both represented as the same {data, error} shape. This code read only contacts.data ?? [] and didn't even destructure error. When the broken filter made PostgREST return an error, data simply became null, no exception was thrown, and ?? [] quietly treated it as a valid "zero contacts matched" result. Every other category — companies, projects, contracts — still matched fine, so the UI just looked like "a slightly thin result set," with no way to notice that the contacts category alone was vanishing for specific search terms.

Fixing it

Name and email were split into separate parameterized .ilike() queries, with the results merged and deduplicated in JS.

// Query name and email separately with parameterized .ilike and merge in JS. Interpolating
// raw input into .or() lets a reserved PostgREST character like a comma break the filter
// grammar, silently dropping the contacts category (e.g. q="Last, First"). .ilike binds its
// value as a parameter, so reserved characters are safe.
supabase
  .from("contacts")
  .select("id, name, email, company_id, school_id")
  .ilike("name", like)
  .limit(5),
supabase
  .from("contacts")
  .select("id, name, email, company_id, school_id")
  .ilike("email", like)
  .limit(5),

.ilike() binds its second argument as a parameter, so a value containing a comma or . — reserved PostgREST characters — doesn't break the filter grammar itself. Because a name match and an email match can return the same contact twice, the merge side uses a Set to push each ID into hits only once.

const seenContact = new Set<string>();
for (const c of [...(contactsByName.data ?? []), ...(contactsByEmail.data ?? [])]) {
  if (seenContact.has(c.id)) continue; // dedupe a contact matched on both name and email
  seenContact.add(c.id);
  hits.push({ ... });
}

To prevent a repeat, a static-guard test now bans raw interpolation into .or() outright:

it("does not interpolate the search query raw into PostgREST .or() filter grammar (injection prevention)", () => {
  expect(src).not.toContain(".or(`");
  expect(src).not.toContain("ilike.${");
});

Because the test inspects the source string directly, CI fails the moment anyone reintroduces a template literal into .or() for the same reason, no matter why.

The lesson

?? [] is a common idiom for "a safe default when there's no value," but combined with a client like supabase-js that represents failure with the same shape as success, it erases the distinction between "zero rows matched" and "the query itself failed." Here the trigger was a different bug — raw interpolation into .or() — but the underlying danger is shared by every call site that reads data without checking error. In a design that bundles several categories into one request via Promise.all, the category that fails is the one that goes quietly missing, and the fact that every other category returns normally is exactly what makes the gap hard to notice.

Originally published at tech.rebounder.jp.

supabase-js try/catch Doesn't Catch Errors: Check { error }

cometa-kaito — Thu, 05 Nov 2026 02:18:47 +0000

Conclusion

supabase-js query methods never throw on network or PostgREST failure. The contract template's current-version resolver branched only on whether data was present, without ever looking at the error that came back alongside it. That meant a transient read failure couldn't be told apart from "no row has been published yet" — and when that return value fed a version-freeze decision, it could freeze an old version the customer never agreed to. The fix: pull the read into its own function, check error explicitly, and fail closed (return null, freeze nothing) when the read itself failed.

What this can look like

The affected code is kimiteras-portal's contract-template resolver (contract-template-store.ts). The advertiser terms start as a JSON file shipped with the code (v1, the baseline, immutable). When an operator publishes a revision from the admin screen, a new version (v2 and up) is inserted into contract_template_versions in the database. Two functions shared the "DB if present, baseline otherwise" logic: getContractTemplate, which returns the body text, and getContractMeta, which returns metadata such as the version number and whether an auto-renewal clause applies.

Before the fix, getContractMeta looked like this:

export async function getContractMeta(
  kind: string
): Promise<ContractMeta | null> {
  try {
    const admin = createSupabaseAdminClient();
    const { data } = await admin
      .from("contract_template_versions")
      .select(SELECT)
      .eq("kind", kind)
      .eq("is_current", true)
      .maybeSingle();
    if (data) return metaOf(data as Row);
  } catch (e) {
    console.error("[contract-template] current meta read failed:", e);
  }
  return getContractMetaBaseline(kind);
}

Only data is destructured from maybeSingle()'s return value — error isn't even pulled out. When the read fails, data simply comes back null; nothing is thrown. So the code has no way to tell whether data is null because no version has been published yet, or because the read itself transiently failed — either case falls through to the same return getContractMetaBaseline(kind) (the baseline v1 metadata).

In the signing flow, freezeSignedTermsSourceVersion sets signed_terms_source_version from this return value, and applyAutoRenewFromSignedTerms later decides whether to turn on auto_renew based on that version's has_auto_renew_clause. The baseline v1 can carry an auto-renewal clause while the current version an operator published (say, v3) doesn't. Every time the read transiently failed, v1 — not the version the customer actually read and agreed to — became the version frozen as the source of truth, opening a path to auto-renewal turning on with no contractual basis.

Cause

supabase-js query methods don't reject their promise. Network errors and PostgREST error responses are both expressed through the same {data, error} return shape. If the caller looks only at data and ignores error, a failure is silently treated as just another case of "no data" — a normal-looking outcome. try/catch is JavaScript's exception mechanism; it can't catch a failure that was never thrown. The mere presence of a catch block gave a false sense that this function was handling failure.

The fix

The current-version read was pulled out into a dedicated function, readCurrentRow, that explicitly checks error and returns {row, failed}:

async function readCurrentRow(
  kind: string
): Promise<{ row: Row | null; failed: boolean }> {
  try {
    const admin = createSupabaseAdminClient();
    const { data, error } = await admin
      .from("contract_template_versions")
      .select(SELECT)
      .eq("kind", kind)
      .order("version", { ascending: false })
      .limit(1)
      .maybeSingle();
    if (error) {
      console.error("[contract-template] current read failed:", error.message);
      return { row: null, failed: true };
    }
    return { row: (data as Row | null) ?? null, failed: false };
  } catch (e) {
    console.error("[contract-template] current read threw:", e);
    return { row: null, failed: true };
  }
}

getContractMeta now branches on that failed flag:

export async function getContractMeta(
  kind: string
): Promise<ContractMeta | null> {
  const { row, failed } = await readCurrentRow(kind);
  if (row) return metaOf(row);
  if (failed) return null;
  return getContractMetaBaseline(kind);
}

When the read fails (failed === true), it returns null and does no version freeze at all — fail-closed. Since the caller, freezeSignedTermsSourceVersion, already does nothing when meta is null, this change alone closes the path where a transient failure kept freezing the wrong version. Only once "no row exists (not yet published)" and "the read failed" were distinguishable did falling back to baseline actually mean what it was supposed to mean: only when nothing had been published.

getContractTemplate, which returns the body text, still falls back to baseline on a read failure — deliberately. "The body can't be shown" would stop the application and signing screens outright, a different trade-off that the team chose to keep, so it's intentionally asymmetric with the fail-closed getContractMeta.

Lesson

This function already had a try/catch at commit time, complete with a console.error in the catch block — whoever wrote it believed they were handling failure. But because supabase-js expresses failure through a return value rather than an exception, the moment only data was destructured, error was silently discarded and that catch block became dead code that could never run. What made this a real defect rather than a minor oversight was that the function's return value fed directly into a version-freeze decision tied to billing.

Originally published at tech.rebounder.jp.

pnpm-lock.yaml Made Vercel Misdetect an npm Project as pnpm

cometa-kaito — Wed, 04 Nov 2026 02:20:09 +0000

Conclusion

The canonical package manager for this repo is npm (package-lock.json), but a pnpm-lock.yaml that had never once been committed to git was still sitting in the working directory, and it made Vercel misdetect the project as pnpm, breaking the build with a type error. Once a .vercelignore file exists, the Vercel CLI stops reading .gitignore, so anything not explicitly listed in .vercelignore gets uploaded — committed or not.

Symptom

Dependency management in this repo is npm, and package.json pins stripe to ^22.3.1.

"stripe": "^22.3.1",

npm resolves that to 22.3.1 and writes it into package-lock.json.

"node_modules/stripe": {
  "version": "22.3.1",
  "resolved": "https://registry.npmjs.org/stripe/-/stripe-22.3.1.tgz",

But the working directory also still had pnpm-lock.yaml and pnpm-workspace.yaml sitting in it, both of which had never once been git added. Pushing the build to Vercel failed with a type error caused by a mismatch in stripe's type definitions.

Cause

.vercelignore originally read like this.

.env*
/scripts
/supabase
/test-results
/README.md

pnpm-lock.yaml is not in that list. Once a .vercelignore file exists, the Vercel CLI decides what to exclude from the upload using only what's written in .vercelignore, and it does not consult .gitignore at all. So the usual assumption — "it's fine, I never pushed it to git" — does not hold here: the untracked pnpm-lock.yaml / pnpm-workspace.yaml files sitting in the working directory were uploaded as-is.

Vercel's build environment detects a project as pnpm based on the presence of pnpm-lock.yaml among the uploaded files. Once that detection lands on pnpm, dependency resolution follows the pnpm lockfile too. In pnpm-lock.yaml, stripe had resolved to

stripe@22.6.0:

which differs from the 22.3.1 that the npm side had pinned. That gap surfaced directly as the type error that broke the build.

The fix

Two lines were added to .vercelignore, explicitly excluding pnpm-lock.yaml and pnpm-workspace.yaml from the upload.

/pnpm-lock.yaml
/pnpm-workspace.yaml

The local files themselves were not deleted. They simply no longer get uploaded to Vercel — .vercelignore remains the single place that decides what gets uploaded, so any untracked file you want excluded still has to be listed there going forward.

Preventing a repeat

This article's sources don't include any record of a mechanical check being added to detect a stray pnpm lockfile. The fix here was also just adding the two files that were found to .vercelignore.

What this exposes structurally is that "not pushed to git" and "not uploaded to Vercel" are two different claims. The moment a .vercelignore file is created at all, the basis for exclusion switches from .gitignore to whatever .vercelignore itself says. An untracked file sitting around locally causes no harm on its own — but in a repo that has a .vercelignore, whether that file is the kind that conflicts with the canonical package manager needs to be checked the moment it appears, not later.

Originally published at tech.rebounder.jp.

DeepL and Whisper Quietly Save Time

cometa-kaito — Mon, 02 Nov 2026 02:28:37 +0000

DeepL — making English read naturally

We use it for reports and replying to email.

The best part is simply that the English reads naturally. There is little of the stiffness that gives machine translation away, and the output is usable as-is.

What actually helped was less the translation quality than the change in order. Even when writing English feels like a chore, switching to "draft in Japanese, then polish" lowers the barrier.

Whisper — transcription that runs locally

We used it when building an app that handles speech recognition.

We picked it because it runs locally and is accurate. Everything stays on the machine, so no audio goes to the cloud. That is strong both for privacy and for offline operation.

It became the first candidate whenever the requirement is "build transcription into my own app".

Choosing between them

Task	Tool
Writing and polishing English	DeepL
Turning speech into text, embedded in an app	Whisper (local)

"Where it runs" as a selection criterion

Putting the two side by side shows that accuracy is not the only axis in a selection.

Accuracy was part of why we chose Whisper, but what really mattered was where it runs. "Audio never goes to the cloud" is not something you can add later the way accuracy can be improved. It is an architectural constraint, and it has to be decided first.

Rather than spending time comparing headline features, deciding "where does it run" and "what leaves the machine" first narrows the options on its own.

Originally published at tech.rebounder.jp.

email_exists on createUser Hides a Silent Signup Failure

cometa-kaito — Fri, 30 Oct 2026 02:19:51 +0000

Conclusion

When Supabase Auth's auth.admin.createUser fails with a duplicate email (email_exists), the code never distinguishes whether the cause is "someone else's existing account" or "a collision with the caller's own prior attempt." In the process that auto-provisions a customer's submission account on every contract signature (provisionCustomerAccount), this failure — until an E2E test caught it on 2026-07-22 — ended at an internal Slack warning only, with nothing changing on the customer's screen or in their inbox. The scope of the 2026-07-23 fix is narrow: it does not change the email-duplicate detection itself, or the logic for looking up and reusing an existing Auth user. All it changes is letting the caller opt in to notifying the customer, and that option is only turned on for the automatic rail triggered by the contract-signing webhook.

Symptom

Once a contract is signed, a customer submission account is auto-provisioned in Supabase Auth (provisionCustomerAccount)
If a Supabase Auth user already exists for the email being used, createUser fails with email_exists, and the function returns reason: "auth_exists"
Previously, this branch only sent an internal warning via notifySlack — no email ever reached the customer, and nothing changed on screen
From the customer's side, they just waited for the submission-account instructions that should follow signing a contract, while in reality nothing was progressing

Cause

provisioning.ts's idempotency check only looks at the profiles table — it never checks whether the Auth-side user is still alive. The code's own comment states this design decision outright.

// provisioning.ts (e5fe39eaf5, lines 118-123)
// 1. Idempotency check: one account per company (§2.4 = company_id × role × is_active).
//    Counted per role (an advertiser's "customer" role and an organization's
//    "group_manager" role are separate accounts). A stale, disabled (is_active=false)
//    account will trigger a "try to re-provision" path, but if an Auth user with the
//    same email is still alive, it later fails with email_exists → auth_exists,
//    falling through to a Slack warning + manual handling (never issue duplicates / §2.6).

In other words, this function was deliberately built to attempt re-provisioning whenever profiles has no active row. But if an Auth user with the same email is still present — whether that's a leftover from the caller's own earlier attempt, or an unrelated person's existing account — createUser fails with the same email_exists, and the function returns the same auth_exists either way, without distinguishing the two.

// provisioning.ts (e5fe39eaf5, lines 148-178)
if (createErr || !created?.user) {
  if (isEmailExistsError(createErr)) {
    // B-1 (actually observed via E2E on 2026-07-22): if an Auth user with the same
    // email already exists, provisioning fails, and previously this ended at a
    // Slack warning only — a silent hole where the customer was told nothing.
    if (!input.notifyCustomerOnConflict)
      return { ok: false, reason: "auth_exists", email };
    const customerNotified = await sendEmail({ /* ... */ });
    return { ok: false, reason: "auth_exists", email, customerNotified };
  }
  return { ok: false, reason: "error", detail: createErr?.message };
}

As the code comment states, at the point the E2E test found this, the notifyCustomerOnConflict branch did not exist at all — auth_exists always ended at a Slack warning and nothing else. There is also a rollback path that deletes the Auth user if the subsequent insert into profiles fails,

// provisioning.ts (e5fe39eaf5, lines 184-196)
if (profErr) {
  await admin.auth.admin.deleteUser(created.user.id);
  return { ok: false, reason: "error", detail: profErr.message };
}

but the return value of that deleteUser call is never checked. If the deletion itself fails, an "orphaned" Auth user with no corresponding profiles row is left behind, and every subsequent provisioning attempt will from then on hit the same auth_exists branch.

The fix

On 2026-07-23, a notifyCustomerOnConflict argument was added to ProvisionInput, letting the caller choose whether the customer gets emailed when auth_exists occurs.

// provisioning.ts (e5fe39eaf5, lines 38-49)
/**
 * Whether to send the customer a notice email when auth_exists occurs (an Auth user
 * with the same email already exists) (B-1). Only true on the automated rail
 * (the contract-signing webhook). Manual provisioning (/admin/users, or allocating
 * to an organization) does not send it, since staff see the result on screen and
 * can act on it directly (this also avoids duplicate sends on every retry).
 */
notifyCustomerOnConflict?: boolean;

The contract-signing webhook (contract-signed.ts) calls this with true, so the customer now also gets an email in addition to the Slack warning.

// contract-signed.ts (f1705230, lines 99-114)
const r = await provisionCustomerAccount({
  companyId,
  // On the automated rail, don't leave the customer silent even on auth_exists
  // (B-1 — send the notice email).
  notifyCustomerOnConflict: true,
});
// ...
: r.reason === "auth_exists"
  ? `⚠️ Submission account could not be provisioned: email ${escapeSlack(r.email ?? "?")} conflicts with an existing user.` +
    `Customer notice email was ${r.customerNotified ? "sent" : "sent⚠ (failed)"}. ` +
    `Please provision manually with a different email address from ${usersLink} ${link}`

The manual provisioning path (/admin/users, or allocating to an organization) does not pass this flag, so it stays at its default of false. Since staff on the manual path see the result on screen in real time and can act on it, sending a customer email here too would mean every retry by staff sends the customer a duplicate notice. That's the reason the scope of the fix is described narrowly as "limited to one path."

What actually happens when auth_exists occurs hasn't changed either. The Slack message still only suggests "please provision manually with a different email address" — there is still no path that looks up and reuses the conflicting existing Auth user.

Generalizing further

The cost of "figuring out whose existing record this actually is, when an existence check fails" gets deferred in most implementations. As this function's own comment shows, the design here deliberately decided: "retry provisioning if profiles has no active row, but fall through to a Slack warning plus manual handling if the Auth side is still alive." That's the right call to avoid issuing duplicates or wrongly linking an account to the wrong company or staff member — but the cost of that call is that the code never investigates whether a conflict traces back to the same person's past failure or to an unrelated third party.

The reason the current fix stops at "tell the customer something" without going as far as "identify the cause of the conflict" is that the underlying design decision itself was never revisited. For a customer who hits auth_exists on the same email, the system can only suggest "try your existing login, or get a new account issued under a different email" — either way, the system has no way to answer what that person actually did here in the past. Before deciding how far up the chain to notify about an existence-check failure, it's worth first checking whether the system is even built to tell what that failure actually means.

Originally published at tech.rebounder.jp.

Three Errors You Actually Hit Connecting Actions to GCP

cometa-kaito — Thu, 29 Oct 2026 02:20:40 +0000

Conclusion

Workload Identity Federation failures come from the configuration living in three layers. The error text does not tell you which one.

GitHub Actions side — does the job have id-token: write?
Pool side — does attribute_condition permit the calling repository?
Service account side — is the roles/iam.workloadIdentityUser binding still there?

Any of the three missing produces similar text. Without deciding the order of investigation up front you end up poking at permissions at random. Below are the three errors we actually hit, in the order you hit them.

Symptom

1. `Unable to acquire impersonation credentials`

The first one you meet. The authentication step itself does not pass. There are three candidate causes, and the higher the layer, the cheaper it is to check.

The job has no permissions with id-token: write. Entirely on GitHub's side, so look here first
You are running from a different repository. The pool's attribute_condition limits the caller via assertion.repository, so forks and other repositories are rejected
The roles/iam.workloadIdentityUser binding on the service account was lost to drift. Restore with terraform apply

The third is the awkward one. The code is correct and it still does not work, and it happens unrelated to any recent change. Someone touching IAM by hand puts Terraform's state and the cloud out of sync, and it surfaces in this shape.

2. `Permission 'iam.serviceAccounts.getAccessToken' denied`

Here impersonation got as far as the entrance and the target service account refused. It looks like a missing grant; in practice it is usually the wrong target.

The service account email is wrong. Where plan and deploy accounts are separate, their permission scopes are separate too. Calling the deploy target with plan credentials is refused, correctly
The environment name does not match. If Terraform's env_name and the GitHub Environment the workflow references diverge, you end up pointed at the wrong service account

The error only says "no permission". It does not say "wrong target", so start by confirming the email is the one you meant.

3. Provider or pool not found

The pool or provider simply does not exist. Check:

gcloud iam workload-identity-pools providers describe <provider-id> \
  --location=global \
  --workload-identity-pool=<pool-id> \
  --project=<project-id>

If it is absent, terraform apply has not been run. Apply in that environment's directory.

Cause

All three share a root: the chain of trust is stored in three separate places.

GitHub issues an OIDC token per job. The pool receives it and decides, through attribute_condition, which repositories it accepts. What passes becomes a principal, and if that principal appears in the service account's IAM policy, impersonation succeeds.

Those three are managed in different places: the workflow YAML, the Terraform pool definition, and the service account IAM policy. Break any one and the chain breaks, but the break is only ever observable as an authentication error.

The fix

Reading the service account IAM policy directly is the fastest way to see the real state.

gcloud iam service-accounts get-iam-policy \
  <sa-name>@<project-id>.iam.gserviceaccount.com \
  --project=<project-id>

The expected state has a principalSet of this shape in members:

principalSet://iam.googleapis.com/projects/<num>/locations/global/workloadIdentityPools/<pool-id>/attribute.repository/<owner>/<repo>

If the calling repository is not there, no amount of fixing the workflow will help. If it is there, the lower two layers are alive and you go and look at permissions on the GitHub side.

You can cut it off immediately

Because there is no JSON key in the setup, there is nothing to rotate. Instead you can stop impersonation from a repository directly.

gcloud iam service-accounts remove-iam-policy-binding \
  <sa-name>@<project-id>.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member='principalSet://iam.googleapis.com/projects/<num>/locations/global/workloadIdentityPools/<pool-id>/attribute.repository/<owner>/<repo>'

The moment the binding is removed, authentication from that repository stops. There is no key expiry to wait for.

But always update Terraform and open a PR afterwards. Leaving a hand-edited IAM policy drifts the configuration, and the binding you removed reappears the next time someone applies. Pair the stopgap with the code change.

And that drift, surfacing much later, is the first error in this article. A neglected emergency cut-off and an unexplained authentication failure are the same thing from two sides.

Making it less likely to recur

The three layers are not going away. What you can change is fixing the order in which you check them.

Cheapest first: permissions on the GitHub side, then get-iam-policy on the service account, then confirming the pool and provider exist. Following that order, the first is just opening a YAML file and the second is one command — enough to narrow down which of the three layers is broken.

For another case where the error text does not lead to the cause, see terraform's enabled = false cannot tear down an environment, where the error appears in a module other than the one at fault.

Originally published at tech.rebounder.jp.

dpm set-device-owner Launches the App Before prefs Is Set

cometa-kaito — Wed, 28 Oct 2026 02:25:39 +0000

Bottom line

dpm set-device-owner is not a command that merely grants a privilege. The instant it succeeds, it launches the target app. If that launch happens before the app's config file (prefs) holds the real device_id, the app sees nothing but an empty config and mints and saves a new id for itself. Worse, once the app is device owner, the usual fix — force-stop — no longer reliably kills it.

Symptom

The provisioning script that turns a factory-reset Google TV into a kiosk unit ran in this order:

Install the kiosk app
Grant device ownership with dpm set-device-owner
am force-stop the app
Write a prefs file containing the correct device_id, delivery URL, and so on
Read prefs back with run-as right after writing, to confirm the value landed

Step 5's read-back always succeeded — reading a value right after writing it is supposed to show what you just wrote. But testing against real hardware on 2026-10-03 found that checking again a little while after provisioning finished, some devices reported a device_id different from the one that had been set.

Cause

As a matter of Android's own behavior, dpm set-device-owner launches the app on the device once ownership is granted. Step 2 in the script did exactly that — before step 4 ever wrote the correct prefs.

At that point prefs is still empty (or holds a previous device's leftover value), so the app takes the same branch it would on any fresh first launch: "no device_id? generate one and save it." That self-generated id ends up in memory, and the process stays running.

Step 3's am force-stop existed precisely to kill this "already running with a self-generated id" process. But once an app is device owner, force-stop no longer fully terminates it. Even though step 4 overwrites the file on disk with the correct value, the still-living process keeps using the id it already has in memory, and depending on timing can write that id back over the file again. The result was a bug whose outcome depended on when you checked: step 5's immediate read-back showed the right value, while checking again moments later showed something else.

Fix

The fix wasn't new code — it was reordering the steps.

 echo "== install APK"
 a install -r "$APK"

-echo "== Device Owner"
-a shell dpm set-device-owner "$PKG/.TvDeviceAdminReceiver"
-a shell dpm list-owners || true
-
 echo "== config (prefs)"
 (... build an XML with device_id, delivery URL, etc ...)
 a shell am force-stop $PKG
 a shell "run-as $PKG sh -c '... write to shared_prefs/tv_ble_bridge.xml ...'"
 a shell "run-as $PKG cat shared_prefs/tv_ble_bridge.xml" | grep -E "device_id|device_label"
+# force-stop no longer works once device-owner is set; to rewrite, write prefs then adb reboot
+
+# device-owner has to come after prefs is written (it launches the app, and with
+# empty prefs the app mints and overwrites its own device_id)
+echo "== Device Owner"
+a shell dpm set-device-owner "$PKG/.TvDeviceAdminReceiver"

Moving dpm set-device-owner to after the prefs write means that by the moment device-owner provisioning launches the app, prefs already holds the real device_id. The app never takes the branch that generates its own; it just reads the value that's already there.

A delayed verification step was also added at the end of the script.

got=$(a shell "run-as $PKG cat shared_prefs/tv_ble_bridge.xml" | grep -o "$DEV" || true)
[ -n "$got" ] && echo "device_id OK" || echo "!! device_id was overwritten -> rewrite prefs and adb reboot"

An immediate read-back couldn't catch the "overwritten later" failure, so the script now re-checks device_id once more after the launch sequence (the part that brings the app to the foreground with am start) has fully run. If it's wrong at that point, adb reboot restarts the device. Force-stop can't kill a device-owner process, but a reboot guarantees it, and the device comes back up reading the correct prefs from disk.

The general shape of this

At its core, this bug is the combination of "an operation that grants a privilege immediately triggers a side effect that uses it" (here, the app auto-launching) with "the precondition that side effect depends on wasn't in place yet" (here, the config file's contents).

For operations where the moment you grant something, code runs — privilege escalation, device-owner provisioning, install-time hooks like BOOT_COMPLETED or a receiver's first launch — confirm config files and secrets are already in place beforehand.
After escalation, the usual remedies that worked before escalation (force-stop, writing with ordinary permissions) can stop working with the exact same command. "It worked a moment ago, so it should still work" is a premise worth re-checking once privilege has changed.
An immediate read-back right after writing can't see a failure that only shows up later. Adding a second check after some time has passed is what actually caught this timing-dependent bug.

Originally published at tech.rebounder.jp.

enabled: false Silently Disabled Claude Code Scheduled Tasks

cometa-kaito — Tue, 27 Oct 2026 03:59:11 +0000

Conclusion

Running Claude Code's scheduled tasks unattended, we found they stop three different ways.

How it stops	What happened	Fix needed
① Never starts	Mac was asleep, or the app was closed	None — it runs automatically on the next launch
② Starts, then dies mid-run	A dropped connection, so the API was never reached	No retry exists. The next slot has to catch up
③ The slot itself gets disabled	`enabled: false`, with no one intending it	Check the list daily and re-enable

None of the three show up in the log of the run that actually happened. That's why we judge by "did the artifact land in git" instead of "did it run."

What's actually running

This blog's (tech.rebounder.jp) articles are written by scheduled tasks in Claude Code's desktop app. There are 6 slots a day: 4 for writing articles (08:06 / 12:08 / 16:05 / 20:07) and 2 for stocking angles and pulling traffic numbers (11:02 / 17:07). We've run this setup for 7 weeks starting 2026-08-16.

Every run happens with no screen, and no human is in the loop. So we can't assume "someone will notice" when something stops.

① Never starts — this one was fine to leave alone

If the Mac is asleep or the app is closed, nothing happens at that time. But this ran automatically the next time the app launched. In one measurement, the 8/17 20:07 slot completed on 8/18 at 09:59.

This isn't the one that needs attention.

② Starts, then dies mid-run — there is no retry

This is the one that hurts. The 2026-08-17 20:02 night slot died 4 minutes after starting, with this error:

API Error: Can't reach the API server (ENOTFOUND)

The log was 12 lines, and not a single file had been touched. It died, so it couldn't record anything itself.

Two days later, on 8/19, the connection dropped for about an hour, and the 11:02 and 12:08 slots died back to back. There was no retry, and that slot was lost for good. Because the run itself dies before reaching the API, writing "retry on failure" into the runbook doesn't help either — there's no process left to read it.

Let the next slot catch up

The only lever we had was "the next slot catches up." Now, at the start of every slot, we count how many articles have gone out today and how many slots have already passed, and write the shortfall in that slot.

We capped the catch-up at 2 articles per run, for three reasons:

Publishing several articles on the same topic in one day collides more easily
The longer one run takes, the higher the chance it dies mid-run — trying to catch up just creates more of failure mode ②
It burns through the stock of material faster

Do the parts you can't recover first

We also changed the order. Traffic numbers only last 7 days on the Cloudflare side, so a day you miss is gone forever. An article, on the other hand, can always be carried over to the next day. So after the 8/19 miss, we made every article-writing slot pull the traffic numbers first, before touching the article. If even one of the 4 slots runs, that day's data is captured.

"It ran" and "it did the work" are not the same thing

The 8/18 10:01 stocking slot has an execution record (a last-run timestamp) showing it ran, but it neither stocked angles nor pulled traffic — it just wrote one file and stopped. It had overlapped with a carried-over run (which finished at 10:02).

If you only look at the execution record, this looks like a success.

③ The slot itself gets disabled — missed for a week

This is the one we missed longest. On 2026-09-27–28, 3 of the 4 article-writing slots had been set to enabled: false. We didn't notice for a week. Daily output dropped from 1–4 articles a day to exactly 1 a day.

The 5 runs right before that had all succeeded — this wasn't caused by a failure. No one remembered disabling it, either. No one intended to stop it.

Our monitoring dashboard did render this as a "failure." But it looked identical to a run that died from a dropped connection, so it got lost among 16 other entries. The root problem was that we weren't distinguishing "one run failed" from "the slot itself is disabled."

Now, at the start of the first slot each day, we list every scheduled task. If a writing slot is set to false, we flip it back to true and add one line to the report: "X was disabled, so I re-enabled it." If we ever want a slot intentionally stopped, its name goes into the runbook as an exception. Any slot not named there gets flipped back on every day.

Judge by the artifact, not by self-report

What all three have in common is that trusting the run's own record misses things. A run that died can't record anything, and a run that merely executed will call itself a "success."

So for every slot we decided which file should land in git if that slot actually did its job — an article file for a writing slot, measurement data for a stocking slot — and we judge by whether that file showed up. The morning and evening stocking slots write to the same kind of file, so they wouldn't be distinguishable from each other; we gave them separate heartbeat files instead.

We measured the wait time instead of guessing it

We'd originally guessed 120 minutes as the time from "run starts" to "artifact appears." Here's what we actually measured from 8/17–8/30:

Slot	Median	Max
08:06 morning article	13 min	113 min
11:02 stocking	107 min	171 min
12:08 midday article	78 min	125 min
16:05 evening article	122 min	163 min
17:07 evening stocking	68 min	130 min
20:07 night article	19 min	169 min

The evening article slot's median exceeded the window itself. Articles were going out, but more than half were showing up as "failed," reporting a 33% success rate. We widened the window to 180 minutes and the false alarms went away. A dashboard that cries wolf eventually gets ignored by everyone.

Bonus: an unattended run stuck waiting for permission

Separate from the three ways of stopping, on day one (2026-08-16) we hit a permission check. Since no one can approve anything in an unattended run, the slot just ends the moment a confirmation prompt appears. There were two causes:

Chaining multiple commands with && or ; doesn't match any entry in the allowlist
cd <dir> && git ... triggers a confirmation every time, because the target directory's git hooks could run. This can't be removed from the allowlist

We avoided both by changing how we write commands: one command per call, specifying the location with git -C <dir> and npm --prefix <dir> instead of cd.

Summary

If you're going to run Claude Code's scheduled tasks unattended, assume they will stop. A run that never started catches up on its own, but a run that died mid-run never comes back, and a disabled slot won't tell anyone. We settled on judging by "did the artifact land," letting the next slot catch up to 2 articles, and pulling unrecoverable data first in every slot.

Originally published at tech.rebounder.jp.

Only Our Vercel API Functions Threw Cannot Find Module

cometa-kaito — Mon, 26 Oct 2026 02:24:52 +0000

Conclusion

Local type-checking and the build don't know that api/ runs unbundled in production. tsconfig.json's moduleResolution: "Bundler" type-checks an extensionless relative import (from "./_lib") as valid, and vite build only bundles the frontend (src/). Both pass — yet the api/ functions, which @vercel/node deploys and runs individually, crashed in production with Cannot find module.

The fix: add the post-build .js extension to every relative import under api/.

Symptom

During an end-to-end check of Kyoshu (a free sponsor-funded polling/Q&A board, its first shipped version) in production, all five API Functions were down: /api/ad (counts sponsor-card views/clicks), /api/cleanup (closes a room), /api/host (host actions), /api/rooms (joining a room), and /api/sponsor (sponsor display). The same code worked fine under local vite dev.

Cause

package.json has "type": "module", so Node.js interprets the code as ESM at runtime.

tsconfig.json sets moduleResolution to "Bundler":

{
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "Bundler",
    ...
  }
}

This mode relaxes type-checking on the assumption that some bundler will resolve the import in the end, so an extensionless relative import (from "./_lib") type-checks as fine. For the frontend (src/), that assumption holds — Vite really does bundle everything at build time.

But api/ is deployed differently. Per vercel.json, @vercel/node deploys each file under api/ as its own serverless function:

{
  "regions": ["hnd1"],
  "crons": [{ "path": "/api/cleanup", "schedule": "0 18 * * *" }],
  ...
}

This path skips Vite's bundling. The TypeScript is transpiled close to 1:1, and the plain Node.js ESM loader resolves the relative import at runtime — and that loader does not allow omitting the extension. Line 3 of ad.ts read:

// before
import { db, isRoomId, today } from "./_lib";

Neither tsc --noEmit nor vite build can catch this line. The former judges it type-valid under moduleResolution: Bundler; the latter never looks at api/ in the first place. The build stays green every time — the failure only surfaces when /api/* is actually hit in production.

Fix

All five files with a relative import from ./_lib — ad.ts, cleanup.ts, host.ts, rooms.ts, sponsor.ts — got the .js extension added to the import:

// after (api/ad.ts)
import { db, isRoomId, today } from "./_lib.js";

The source file stays .ts. TypeScript allows writing the post-build extension (.js) in a relative import under both moduleResolution: Bundler and NodeNext. Since what actually runs in production is the compiled .js, that's the only extension the Node.js ESM loader can resolve _lib with.

Why it went unnoticed

moduleResolution: "Bundler" is written for the frontend build and local development (vite dev) — both of which really do get bundled by Vite, so the extension never matters there.

But api/ is deployed separately, one function at a time, by @vercel/node, bypassing Vite's bundling entirely. tsconfig.json's include does list api, but moduleResolution's own behavior has no concept of "api/ alone runs on a different runtime." Both type-checking and the build stayed green; the mismatch only showed up as a production runtime error.

Originally published at tech.rebounder.jp.

gcloud ADC Expires After ~44h: Reauthentication failed Fix

cometa-kaito — Fri, 23 Oct 2026 08:50:49 +0000

The short version

Credentials created with gcloud auth application-default login (ADC) could not keep a headless scheduled job running. They expired after about 44 hours, and every run stopped here:

Reauthentication failed. cannot prompt during non-interactive execution.

The account behind the login was a Google Workspace account with a reauthentication policy. A scheduled job has no screen, so nobody can type the password again. Once it expires, it never works again.

The fix was to authenticate with a service account key instead. A service account has no expiry and no reauthentication.

What the job does

This blog (tech.rebounder.jp) is written every day by an AI agent running with no screen. As part of that run, a step pulls impressions, clicks, and average position from the Search Console API and writes them to a file. It doesn't use a client library — it calls the API directly with Node.js fetch.

On 2026-08-30 it first worked with local ADC:

gcloud auth application-default login
gcloud auth application-default print-access-token

Put that token in Authorization: Bearer and the API answers. Run by hand, nothing looked wrong.

It expired after about 44 hours

It broke about 44 hours later, on 2026-09-01. The Reauthentication failed. cannot prompt during non-interactive execution. error above appeared, and every run after that stopped at the same place.

The cause is the account type. The login was a company Workspace account, and Workspace applies a reauthentication policy. It periodically asks for the password again, and a scheduled job has no screen to answer with.

Automation that needs a human to log in again every couple of days isn't automation. That's where ADC stopped being the main path.

Switching to a service account

Build a JWT from the service account key (JSON) and exchange it for an access token yourself. It only needs node:crypto — no library.

const sa = JSON.parse(readFileSync(SA_KEY, 'utf8'));
const now = Math.floor(Date.now() / 1000);
const b64 = (o: unknown) => Buffer.from(JSON.stringify(o)).toString('base64url');
const unsigned = `${b64({ alg: 'RS256', typ: 'JWT' })}.${b64({
  iss: sa.client_email,
  scope: 'https://www.googleapis.com/auth/webmasters.readonly',
  aud: 'https://oauth2.googleapis.com/token',
  iat: now,
  exp: now + 3600,
})}`;
const sig = createSign('RSA-SHA256').update(unsigned).sign(sa.private_key, 'base64url');
const res = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer',
    assertion: `${unsigned}.${sig}`,
  }),
});

Three decisions went with it:

The key lives outside the repository (a config folder under the home directory) with 600 permissions
The service account has no GCP roles at all. Its only permission is "can read this property," granted on the Search Console side. If the key leaks, all it can do is read this blog's search data
Register the service account's email address under "Add user" in Search Console. Restricted permission is enough for reading

The ADC path is still in the code, but it isn't relied on, because Workspace reauthentication will break it.

403 comes back with three different causes

The switch hit 403 several times. The hard part: "missing scope," "wrong account," and "wrong project" all come back as the same 403. Until you can tell which one it is, you can't find the right fix.

ADC needs a quota project header

With personal-account ADC and a raw fetch, the API returned 403 SERVICE_DISABLED even with the right scope (2026-08-30). The message reads like a permissions problem, so it's easy to misread as a scope issue.

The real cause was the missing quota project (the project API usage is billed to). gcloud auth application-default set-quota-project configures client libraries — it has no effect on a raw fetch. You have to send it as a header:

headers: { Authorization: `Bearer ${token}`, 'x-goog-user-project': '<project-id>' }

A service account must not send it

Send that same header with a service account, though, and it causes a 403 of its own (2026-09-01). A service account implicitly bills to the project it belongs to. Adding x-goog-user-project on top means the service account itself needs the serviceUsageConsumer role, which it doesn't have, so the call is rejected.

The header is only for ADC. The code sends it depending on which auth path produced the token:

const quotaHeader = saToken ? {} : { 'x-goog-user-project': QUOTA_PROJECT };

Logged in as a different account

Even after fixing the quota project, 403 kept coming. This time the login was a different account. The property list didn't include the target site.

And because the login had used --scopes, the default email scope was dropped, so there was no way to show who was logged in. The recommended login command now adds openid,email to the scopes, and the token's email address is printed first. Before calling the API, the job now checks that the target site is in the property list; if it isn't, it prints "which account, and what it can see" and stops.

A small trap: gcloud won't start on Python 3.9

This Mac's default Python is 3.9, and gcloud wouldn't start on it. When the ADC path runs gcloud as a child process, it sets CLOUDSDK_PYTHON to 3.10.

Don't write "0" on a day it failed

One more change was how failure is handled. When the API can't be reached, the previous values are kept and only an error is recorded. Showing "0 impressions" on the day the API was down is the worst way for this to break.

Takeaway

Reauthentication failed. cannot prompt during non-interactive execution shows up when ADC was created with an account that needs human reauthentication and is then used by a job with no screen. It should look the same from cron, CI, or an AI agent's scheduled run. For anything unattended, use a service account. Then, if you get a 403, figure out first whether it's the scope, the account, or the project — it saves a long detour.

Originally published at tech.rebounder.jp.

DEV Community: cometa-kaito

Bing Webmaster UrlCount Stuck at 1: the sitemap-index Trap

Conclusion first

IndexNow alone isn't enough

Bing Webmaster counts UrlCount as 1 and stops

Day-to-day operation: register the sitemap and submit URLs, both

A second trap: treating a rename as delete-plus-add

Cost

Summary

vercel inspect won't show which commit is live

Starting with the conclusion

Symptom

Cause

Fix

Prevention

PostgREST .or() Breaks Silently on a Comma

The short version

The state it could become

Why

Fixing it

The lesson

supabase-js try/catch Doesn't Catch Errors: Check { error }

Conclusion

What this can look like

Cause

The fix

Lesson

pnpm-lock.yaml Made Vercel Misdetect an npm Project as pnpm

Conclusion

Symptom

Cause

The fix

Preventing a repeat

DeepL and Whisper Quietly Save Time

DeepL — making English read naturally

Whisper — transcription that runs locally

Choosing between them

"Where it runs" as a selection criterion

email_exists on createUser Hides a Silent Signup Failure

Conclusion

Symptom

Cause

The fix

Generalizing further

Three Errors You Actually Hit Connecting Actions to GCP

Conclusion

Symptom

1. Unable to acquire impersonation credentials

2. Permission 'iam.serviceAccounts.getAccessToken' denied

3. Provider or pool not found

Cause

The fix

You can cut it off immediately

Making it less likely to recur

dpm set-device-owner Launches the App Before prefs Is Set

Bottom line

Symptom

Cause

Fix

The general shape of this

enabled: false Silently Disabled Claude Code Scheduled Tasks

Conclusion

What's actually running

① Never starts — this one was fine to leave alone

② Starts, then dies mid-run — there is no retry

Let the next slot catch up

Do the parts you can't recover first

"It ran" and "it did the work" are not the same thing

③ The slot itself gets disabled — missed for a week

Judge by the artifact, not by self-report

We measured the wait time instead of guessing it

Bonus: an unattended run stuck waiting for permission

Summary

Only Our Vercel API Functions Threw Cannot Find Module

Conclusion

Symptom

Cause

Fix

Why it went unnoticed

gcloud ADC Expires After ~44h: Reauthentication failed Fix

1. `Unable to acquire impersonation credentials`

2. `Permission 'iam.serviceAccounts.getAccessToken' denied`