DEV Community: ACS Developer

You Can Upload but Not Edit: YouTube Data API Scopes and publishAt Scheduled Publishing

ACS Developer — Mon, 14 Sep 2026 13:54:15 +0000

Automating YouTube uploads with scheduled publishing produced three failures that never raised an error: youtube.upload cannot call videos.update, a token can silently belong to the wrong channel, and publishAt is ignored unless privacyStatus is private.

What I wanted

Export one short video a day and publish it at a fixed time the next day. I automated the part where "once the exported file is in place, everything runs through to scheduled publishing" with the YouTube Data API v3.

Done by hand it is five steps: open Studio, pick the video, paste in the title and description, swap the thumbnail, and enter the scheduled publish time. On the API side it looks like you just pass status.publishAt to videos.insert and you are done. In practice I tripped twice before that and once after. All of them were the kind where no error appears, but you end up in a state other than the one you intended.

Trip 1: the `youtube.upload` scope only lets you upload

I had already written the operations runbook: "if you get the title wrong, videos.delete and re-upload with the same publishAt."

Then I actually tried to fix the title of an uploaded video and got this:

HTTP Error 403: Forbidden   (reason: insufficientPermissions)

videos.insert works with the same token. Only videos.update fails. The cause was the scopes attached to the token.

# before re-issuing
SCOPES = [
    "https://www.googleapis.com/auth/youtube.upload",
    "https://www.googleapis.com/auth/youtube.readonly",
    "https://www.googleapis.com/auth/yt-analytics.readonly",
]

youtube.upload is, as the name says, the scope for uploading: videos.insert and thumbnails.set work. But videos.update and videos.delete do not. Adding the read-only youtube.readonly does not add any write permission. That combination of three produces a token that "can post, but can never touch what it posted".

To include writes you need the full scope https://www.googleapis.com/auth/youtube.

SCOPES = [
    "https://www.googleapis.com/auth/youtube",        # videos.update / videos.delete
    "https://www.googleapis.com/auth/youtube.upload",
    "https://www.googleapis.com/auth/youtube.readonly",
    "https://www.googleapis.com/auth/yt-analytics.readonly",
]

What you have to watch out for is that scopes do not grow onto an existing refresh token later. Scopes are frozen at what was approved on the consent screen, so once you edit SCOPES you have to run the OAuth flow from the start and re-issue (with prompt=consent to force re-consent). Until the token file is overwritten, the 403 will not go away no matter how correct the constant in your code is.

The operational lesson was the bigger one: if you write a runbook on the premise that "you can just fix mistakes through the API", the whole runbook collapses when your scopes are insufficient. I ended up rewriting three steps into "re-upload with the same publishAt and delete the old one by hand."

Trip 2: which channel does that token belong to?

If you run multiple channels, you can grab the wrong token file and upload a video to a completely different channel. And since the upload itself succeeds, no error tells you.

Add one check before posting.

me = api_get("https://www.googleapis.com/youtube/v3/channels"
             "?part=snippet&mine=true", H)
ch = me["items"][0]
print(ch["id"], ch["snippet"]["title"])  # UCxxxxxxxxxxxxxxxxxxxxxx  <channel name>

I made it standard to run this before executing. It is one request, and absurdly cheap compared to the cost of recovering from the accident (if you do not notice before publication, it goes public on the wrong channel).

Implementation: resumable upload and `publishAt`

The main flow is a resumable upload: send the metadata first, receive a Location, and PUT the body there in chunks.

meta = {
    "snippet": {
        "title": title, "description": desc, "tags": tags,
        "categoryId": "22",
        "defaultLanguage": "ja", "defaultAudioLanguage": "ja",
    },
    "status": {
        "privacyStatus": "private",          # required together with publishAt
        "publishAt": "2026-09-11T10:45:00Z",  # UTC
        "selfDeclaredMadeForKids": False,
        "license": "youtube", "embeddable": True,
    },
}

size = VIDEO.stat().st_size
req = urllib.request.Request(
    "https://www.googleapis.com/upload/youtube/v3/videos"
    "?uploadType=resumable&part=snippet,status",
    data=json.dumps(meta).encode(), method="POST",
    headers={**H, "Content-Type": "application/json; charset=UTF-8",
             "X-Upload-Content-Length": str(size),
             "X-Upload-Content-Type": "video/mp4"})
with urllib.request.urlopen(req, timeout=60) as r:
    loc = r.headers["Location"]

The value of privacyStatus is what matters here. publishAt has no effect unless it is paired with privacyStatus: "private". Pass publishAt while leaving it public and it is not scheduled — it simply publishes. No error is returned.

On the body-sending side, the only thing to watch is how you handle 308.

CH = 32 * 1024 * 1024
sent, vid = 0, None
with open(VIDEO, "rb") as f:
    while sent < size:
        chunk = f.read(CH)
        end = sent + len(chunk) - 1
        rq = urllib.request.Request(
            loc, data=chunk, method="PUT",
            headers={**H, "Content-Type": "video/mp4",
                     "Content-Range": f"bytes {sent}-{end}/{size}"})
        try:
            with urllib.request.urlopen(rq, timeout=600) as r:
                if r.status in (200, 201):
                    vid = json.loads(r.read())["id"]
        except urllib.error.HTTPError as e:
            if e.code != 308:      # 308 = continue. Not an error.
                print("ERR", e.code, e.read()[:300])
                sys.exit(1)
        sent = end + 1

urllib raises 308 as an exception, so catch HTTPError and swallow only 308. Only the response to the final chunk carries the id.

The thumbnail goes to thumbnails.set as a separate request. The export side emits PNG, so there is a conversion step that pins it to JPEG (if Content-Type and the actual contents disagree it is rejected, so do not leave it to the file extension).

thumb = D / "thumbnail_upload.jpg"
if not thumb.exists() and (D / "thumbnail.png").exists():
    from PIL import Image
    Image.open(D / "thumbnail.png").convert("RGB").save(
        thumb, "JPEG", quality=92, optimize=True)

Trip 3: killing off "I thought it was scheduled"

This was the most effective countermeasure. A 200 from videos.insert only guarantees that a video was created. Whether the publishAt you passed actually took is a separate matter — if the privacyStatus does not line up, it quietly finishes without ever being scheduled.

Read it back immediately after upload and compare.

st = api_get("https://www.googleapis.com/youtube/v3/videos"
             f"?part=status,contentDetails&id={vid}", H)["items"][0]
publish_at = st["status"].get("publishAt")
ok = (st["status"]["privacyStatus"] == "private"
      and publish_at is not None
      and _iso(publish_at) == _iso(requested))

# ... after writing the result out as JSON
if not ok:
    sys.exit("ERR: failed to verify privacyStatus/publishAt")

Normalize before comparing. The publishAt the API returns is sometimes 2026-09-11T10:45:00Z and sometimes in +00:00 notation, so a plain string comparison fails on values that should pass.

def _iso(s: str):
    from datetime import datetime, timezone
    return datetime.fromisoformat(s.replace("Z", "+00:00")).astimezone(timezone.utc)

After adding this I scheduled two videos and measured verified: true for both (privacyStatus=private and publishAt matching the requested value). The verification result is written straight into the delivery folder.

{
  "video_id": "xxxxxxxxxxx",
  "privacy": "private",
  "publishAt": "2026-09-11T10:45:00Z",
  "publishAt_requested": "2026-09-11T10:45:00Z",
  "verified": true,
  "duration": "PT26S"
}

Stopping double uploads

Since the script runs automatically, running it twice against the same folder lines up two copies of the same video. I used that upload_result.json directly as the idempotency key.

result_path = D / "upload_result.json"
if result_path.exists() and not a.force:
    prev = json.loads(result_path.read_text(encoding="utf-8"))
    print(f"Already uploaded: {prev.get('video_id')}. Use --force to re-run.")
    return

Add --force only when you actually want to re-run. The API has no way to tell whether two uploads are "the same video", so the caller has to own that.

Summary

youtube.upload is upload-only. videos.update / videos.delete need the full youtube scope
After adding a scope, re-issue the OAuth token. Scopes do not grow onto an existing token
Write runbooks that assume "if it breaks, fix it through the API" only after checking your scopes
publishAt is ignored unless paired with privacyStatus: "private" (and no error is raised)
A 308 in a resumable upload is not an error
After posting, read back with videos.list(part=status) and normalize times to UTC before comparing

This is an area with that many "failures that raise no error", so judging by the state you read back, rather than by the response of an API that returned success, turned out to be the cheapest approach in the end.

I publish further verification records and related tools on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/youtube-data-api-upload-scope-publish-at

Drop session_start() from Your Paywall: HMAC-Signed Cookies and Single-Use Recovery Links

ACS Developer — Mon, 14 Sep 2026 13:48:43 +0000

session_start() does not just lose a paywall purchaser when the browser closes — it kills page caching for every visitor. Here is the replacement: an HMAC-signed cookie plus a single-use recovery link, and the design decisions behind both.

Premise: sessions cannot coexist with page caching

When you build paid articles (a paywall) that can be bought without registering an account, the first thing you decide is: "how do I remember, on the next request, that this reader is a purchaser?"

The old implementation I maintained did this with session_start() and $_SESSION. It works, but it has two problems.

It disappears when the browser closes. A purchaser returning the next day looks like they have to buy again
It collides with page caching. session_start() emits headers equivalent to Cache-Control: no-store and hands Set-Cookie: PHPSESSID=... to every visitor. Most CDNs and page caches will not cache a response carrying Set-Cookie, so caching is effectively disabled for everyone, purchasers and non-purchasers alike

The second one was fatal. A paywall is normally shaped as "most of the article is free, only the continuation is paid", so the free portion is exactly where caching should be working.

This article records the design that replaced it, in two parts, and the judgment calls I made while implementing it.

An HMAC-signed cookie (90 days by default) identifies the reader without server-side state
A single-use link (24 hours by default, one use) restores access from another device

The code is from a WordPress plugin, but the design of signed cookies and single-use links is framework-independent.

1. A signed cookie with no server-side state

The cookie contents are two parts: base64url(email|expires) . '.' . hmac.

public function build_cookie_value( $email, $expires ) {
    $email = ACSCW_Access::normalize_email( $email );

    if ( '' === $email ) {
        return '';
    }

    $payload   = $email . '|' . (int) $expires;
    $encoded   = self::base64url_encode( $payload );
    $signature = hash_hmac( self::ALGO, $encoded, $this->get_signing_key() );

    return $encoded . '.' . $signature;
}

There are three things to be careful about on the verification side.

public function verify_cookie_value( $raw ) {
    $raw = (string) $raw;

    if ( '' === $raw || substr_count( $raw, '.' ) !== 1 ) {
        return false;
    }

    list( $encoded, $signature ) = explode( '.', $raw, 2 );
    $expected = hash_hmac( self::ALGO, $encoded, $this->get_signing_key() );

    // Compare with hash_equals to avoid timing attacks.
    if ( ! hash_equals( $expected, $signature ) ) {
        return false;
    }

    $payload = self::base64url_decode( $encoded );

    if ( false === $payload || false === strpos( $payload, '|' ) ) {
        return false;
    }

    // Take expires from the end, so an email containing '|' is still fine.
    $parts   = explode( '|', $payload );
    $expires = (int) array_pop( $parts );
    $email   = ACSCW_Access::normalize_email( implode( '|', $parts ) );

    if ( '' === $email || $expires <= time() ) {
        return false;
    }

    return array( 'email' => $email, 'expires' => $expires );
}

Compare signatures with hash_equals. === varies in execution time by how many leading characters match, so do not use it
Do not fix the split count of explode. Take only the trailing expires with array_pop and rejoin the rest. That structurally prevents the "delimiter appears inside the value" class of mistake
Put the expiry inside the payload so it is covered by the signature. The cookie's own expires attribute can be freely ignored by the client, so do not rely on it alone

Keep the signing key separate from the framework's salt

WordPress has an existing key, wp_salt('auth'), but rather than using it directly I mix in a plugin-specific random key.

private function get_signing_key() {
    $secret = get_option( self::KEY_OPTION );

    if ( ! is_string( $secret ) || strlen( $secret ) < 32 ) {
        $secret = wp_generate_password( 64, false, false );
        update_option( self::KEY_OPTION, $secret, false );
    }

    return hash_hmac( self::ALGO, $secret, wp_salt( 'auth' ) );
}

The purpose is one operational capability: being able to invalidate every access cookie you have issued, without taking login sessions down with it. Throwing away one dedicated option expires all issued access cookies at once. If you used the shared salt directly, that operation would force-log-out every user.

Cookie attributes on emission: httponly, samesite=Lax, secure depending on is_ssl(), and the name carries COOKIEHASH (to avoid collisions when several sites share a domain).

2. You cannot put a nonce in a single-use link

Recovery on another device goes out by email. The first thing that tripped me up here was handling the CSRF token (a nonce, in WordPress terms).

You cannot put a nonce in an emailed link. A nonce is bound to "the person who has this session right now", and at the moment you send the email you do not know which browser or session the recipient will open it in. You cannot create a nonce that will be valid at send time.

Instead, treat the 48-character single-use token itself as the credential.

public function create_one_time_token( $email, $post_id = 0 ) {
    $token = wp_generate_password( 48, false, false );

    $stored = set_transient(
        self::TOKEN_TRANSIENT_PREFIX . self::hash_token( $token ),
        array( 'email' => $email, 'post_id' => absint( $post_id ) ),
        $this->get_token_lifetime()
    );
    // ...
    return $token;
}

What is stored is only the hash of the token. The raw value exists nowhere except the body of the email. Even if storage leaks, no valid link can be assembled from it. It is the same reasoning as not storing passwords in plain text, applied to a temporary token with a 24-hour lifetime.

On the consuming side, delete it the moment it is read.

public function consume_one_time_token( $token ) {
    $token = preg_replace( '/[^A-Za-z0-9]/', '', (string) $token );

    if ( '' === $token ) {
        return false;
    }

    $key   = self::TOKEN_TRANSIENT_PREFIX . self::hash_token( $token );
    $value = get_transient( $key );

    // Single use. Delete it as soon as it is readable.
    delete_transient( $key );

    if ( ! is_array( $value ) || empty( $value['email'] ) ) {
        return false;
    }
    // ...
}

The point is that delete_transient() sits before validation. Put it after, and as soon as you add another early-return path in validation, you create a path that skips the deletion.

Do not leave the token in the URL

The handler for an opened link issues the cookie, then drops the query variable and redirects to the same URL.

public function maybe_consume_access_link() {
    if ( empty( $_GET[ self::QUERY_VAR ] ) ) {
        return;
    }

    $token  = sanitize_text_field( wp_unslash( $_GET[ self::QUERY_VAR ] ) );
    $result = $this->consume_one_time_token( $token );

    if ( $result ) {
        $this->issue_cookie( $result['email'] );
    }

    $redirect = remove_query_arg( self::QUERY_VAR );

    if ( ! $result ) {
        // Put the failure reason in the URL (never the email address).
        $redirect = add_query_arg( 'acscw_notice', 'link_expired', $redirect );
    }

    wp_safe_redirect( $redirect );
    exit;
}

A URL with the token still in it leaks through browser history, the Referer header, and pasting into social media. The actual harm is small since it is already used, but having it gone from the address bar saves the reader from wondering "is this URL safe to share?".

Also, the entry point is template_redirect at priority 1, not REST or AJAX. Email links are opened as ordinary GET requests, so handling them at the very front of a normal front-end request and redirecting was the natural fit.

3. Do not turn the recovery form into an email existence oracle

This was the easiest place in the design to get wrong. A form that says "send an access link to this email address" becomes a purchaser-lookup API if you implement it naively.

public function request_access_link( $email, $post_id = 0 ) {
    // ... format check, rate limiting ...

    // Return true even when there is no purchase. Miss this branch and it becomes an existence oracle.
    if ( ! $access->has_any_access( $email ) ) {
        return true;
    }

    $token = $this->create_one_time_token( $email, $post_id );
    // ... send mail ...
    return true;
}

An address with no purchase gets exactly the same result (true) as a purchaser. Mail is actually sent only when there is a purchase. The screen always says "We have sent an access link. If it does not arrive, please check your spam folder."

The only cases where returning WP_Error is acceptable are malformed input and rate-limit exceeded. Those two are unrelated to whether the address is registered, so returning them leaks nothing.

Rate limiting on two axes, with no raw values in the key

The submit form can be hit infinitely, so it is throttled on two axes: per email address (180 seconds between requests by default) and per IP (10 per hour by default).

private function get_rate_key( $scope, $value ) {
    return self::RATE_TRANSIENT_PREFIX . $scope . '_'
        . substr( hash_hmac( self::ALGO, (string) $value, $this->get_signing_key() ), 0, 32 );
}

Do not put a raw email address or IP into a transient key. Key names can show up verbatim in cache admin screens and debug output, and you do not want that to become a store of personal data. Flattened through an HMAC, a listing of the keys tells you nothing about whose they are.

IP retrieval prefers WC_Geolocation::get_ip_address() since WooCommerce is assumed present. Aligning with the framework you already live alongside causes fewer accidents than deciding your own proxy-handling policy.

4. Verification results

The design is regression tested on a shim harness that runs under plain PHP. Re-running it at the time of writing gave the following (PHP 8.5.7 / CLI):

== 5. Signed cookies (ACSCW_Access_Token)
  PASS  cookie value contains no raw email address
  PASS  changing one character of the signature fails
  PASS  an expired cookie does not verify
  PASS  changing the signing key invalidates existing cookies
== 6. Single-use links
  PASS  the raw token is not stored (hash only)
  PASS  the same token cannot be used twice (single use)
  PASS  a token with symbols mixed in does not raise
  PASS  the token is removed from the redirect target
== 7. Access recovery requests, rate limiting, mail
  PASS  the same result is returned even without a purchase (prevents existence probing)
  PASS  no mail is sent to a non-purchaser
  PASS  repeated requests from one IP stop at the limit

----------------------------------------
PASS 168 / FAIL 0

What works well here is encoding the design decisions themselves as tests. "Changing the signing key invalidates existing cookies" and "the same result is returned even without a purchase" are exactly the properties a refactor breaks if you do not know the spec — and when they break, the screen still looks fine. The test names double as the specification.

Summary

The motivation for dropping sessions is not only "it disappears" but, more importantly, "it kills caching for every visitor"
Build signed cookies on three things: hash_equals, an expiry inside the payload, and a dedicated signing key
You cannot put a nonce in an emailed link. Make the single-use token itself the credential, and store only the hash, delete before validating
The recovery form returns the same response for unregistered addresses. Only malformed input and rate-limit exceeded may be errors
Never put a raw email address or IP into a rate-limit key

I publish further verification records and related tools on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/signed-cookie-one-time-link-paywall

Guarding the_content Is Not Enough: Six Routes That Leak Paid Content in a WordPress Paywall

ACS Developer — Mon, 14 Sep 2026 13:43:09 +0000

Paid content in a WordPress paywall lives in post_content as plain text, and WordPress hands it out through six different exits — here are all six, the code that closes them, and the harness assertions that prove nothing leaks.

While rebuilding a per-article paid content plugin, I found that I had been implementing "hide the paid body" in entirely the wrong place. The old version only protected the body rendering (the_content), but WordPress emits that same body through six routes. This article lists those routes, shows the code that actually closed them, and records how I mechanically verified that nothing leaks.

Premise: the paid body stays in `post_content` as plain text

If you build a paywall with the block editor, the paid body is saved as InnerBlocks of a Paywall block. If you set save to null (a fully dynamic block), the paid body itself disappears on save. So save has to be InnerBlocks.Content, and that settles the following:

The paid body is sitting in post_content as-is. You cannot hide it at save time. You have to drop it on every output route.

If you think in terms of "cut it only when the body is rendered", this is where you leak.

The six exposure routes

An unpurchased reader's response can carry the paid body through at least these six routes:

#	Route	Mechanism
1	Single page	`the_content`
2	Auto excerpt	`wp_trim_excerpt()` → `the_content`
3	RSS/Atom body	`get_the_content_feed()` → `the_content`
4	RSS excerpt	`the_excerpt_rss`
5	oEmbed excerpt	`the_excerpt_embed`
6	REST `content.rendered`	`WP_REST_Posts_Controller` → `the_content`

The important part is that 1, 2, 3 and 6 all end up passing through the_content. Close that one place and four routes are handled at once. Conversely, 4 and 5 do not pass through the_content, so they need closing individually. REST's content.raw requires edit permission, so core's own protection is enough there.

Net 1: drop the blocks in `the_content` at priority 5

do_blocks runs at priority 9 and wpautop at 10. Before those, parse while the content is still block markup, throw away the Paywall block and everything after it, and re-serialize. Keeping that order means the string of the paid body simply does not exist in an unpurchased reader's response (this is not hiding with CSS or removing with JS).

public function __construct() {
    // Priority 5. Split the body before do_blocks (9) and wpautop (10).
    add_filter( 'the_content', array( $this, 'filter_the_content' ), 5 );

    // Routes that do not pass through the_content.
    add_filter( 'get_the_excerpt', array( $this, 'filter_excerpt' ), 5, 2 );
    add_filter( 'the_excerpt_rss', array( $this, 'filter_excerpt_rss' ), 5 );
    add_filter( 'the_excerpt_embed', array( $this, 'filter_excerpt_rss' ), 5 );
}

public function filter_the_content( $content ) {
    if ( ! is_string( $content ) || '' === $content ) {
        return $content;
    }

    // No blocks, pass through (do not break unrelated the_content usage).
    if ( ! self::content_has_paywall( $content ) ) {
        return $content;
    }

    $post_id = self::current_post_id();

    if ( self::reader_can_read( $post_id ) ) {
        return $content;
    }

    if ( ! function_exists( 'parse_blocks' ) || ! function_exists( 'serialize_blocks' ) ) {
        // In an environment where we cannot split, drop everything rather than emit paid content.
        return '';
    }

    $split = self::split_blocks( parse_blocks( $content ) );

    if ( ! $split['found'] ) {
        return $content;
    }

    return serialize_blocks( $split['blocks'] );
}

After truncating, place a single "Paywall block with attributes preserved but no inner content". That is what do_blocks hands to the render callback, and it becomes the box holding the purchase flow.

Nesting: drop the whole parent

If the Paywall sits inside a group or columns block, discard the entire top-level parent. Extracting only the inner part risks dragging fragments of the paid body out with the parent's decoration or layout.

foreach ( $blocks as $block ) {
    $paywall = self::find_paywall( $block ); // search nesting recursively

    if ( null === $paywall ) {
        $kept[] = $block;
        continue;
    }

    $found = $paywall;
    break;
}

The hole in net 1: excerpts do not always pass through `the_content`

Auto excerpts go through wp_trim_excerpt() and therefore the_content, but the_excerpt_rss and the_excerpt_embed hand you an already-generated excerpt string. They also do not pass the post object as a second argument, so the filter has to consult the global post.

public function filter_excerpt_rss( $excerpt ) {
    return $this->filter_excerpt( $excerpt, null ); // inside: get_post( null ) → current post
}

And an excerpt should not be "erased" but rebuilt from the free portion. An empty excerpt on index pages is a loss for both the reader and the site. A post_excerpt written by hand is respected as-is (a machine should not overwrite something written deliberately).

private function build_free_excerpt( $post ) {
    $split = self::split_blocks( parse_blocks( $post->post_content ) );
    $free  = array();

    foreach ( $split['blocks'] as $block ) {
        if ( isset( $block['blockName'] ) && in_array( $block['blockName'], self::get_block_names(), true ) ) {
            continue; // the empty Paywall block is not wanted in the excerpt either
        }
        $free[] = $block;
    }

    $text = wp_strip_all_tags( strip_shortcodes( serialize_blocks( $free ) ) );
    $text = trim( preg_replace( '/\s+/u', ' ', str_replace( array( "\r", "\n", "\t" ), ' ', $text ) ) );

    return wp_trim_words( $text, (int) apply_filters( 'excerpt_length', 55 ), apply_filters( 'excerpt_more', ' [&hellip;]' ) );
}

The output of serialize_blocks() contains block comments like . wp_strip_all_tags() removes HTML comments along with tags, so without passing through it the comments end up inside the excerpt.

Fail closed in two places

When the information needed for a decision is unavailable, write explicitly that it must not fall back to "readable".

public static function current_post_id() {
    if ( isset( $GLOBALS['post'] ) && is_object( $GLOBALS['post'] ) && isset( $GLOBALS['post']->ID ) ) {
        return absint( $GLOBALS['post']->ID );
    }

    if ( function_exists( 'get_the_ID' ) ) {
        $post_id = get_the_ID();
        if ( $post_id ) {
            return absint( $post_id );
        }
    }

    return 0; // 0 falls back to "not readable"
}

Cannot determine the post ID → return 0, and the purchase check is always false
Environment without parse_blocks() / serialize_blocks() → empty the body entirely

Both fall to "emit nothing when broken" rather than "leak when broken".

Net 2: check again in the render callback

For rendering routes that do not pass through net 1 (a direct render_block() call, block rendering inside a template, and so on), run the purchase check in the render callback as well. If net 1 worked, $content is already empty, so cutting twice has no side effect.

public function render( $attributes, $content = '', $block = null ) {
    $post_id = self::current_post_id();

    if ( self::reader_can_read( $post_id ) ) {
        return (string) $content; // purchasers and editors get the full body
    }

    return $this->render_box( (array) $attributes, $post_id );
}

Old posts saved with a previous block name also need that old name in the array of block names being checked. Forget this and only the articles written with the old block leak their paid body raw. In a plugin that involves a migration, that one line is effectively a vulnerability.

Verification: assert that nothing leaked

Being correct by design is a separate question from actually not leaking, so the test harness asserts per route that a marker string from the paid body does not appear in the output.

$excerpt = apply_filters( 'get_the_excerpt', '', $paid_post );
t( '* auto excerpt contains no paid body', false === strpos( $excerpt, ACSCW_TEST_PAID ), $excerpt );
t( 'auto excerpt is built from the free portion', false !== strpos( $excerpt, '無料で読める' ), $excerpt );

$rss = apply_filters( 'the_excerpt_rss', '<p>' . ACSCW_TEST_PAID . '</p>' );
t( '* RSS excerpt contains no paid body', false === strpos( $rss, ACSCW_TEST_PAID ), $rss );

$embed = apply_filters( 'the_excerpt_embed', '<p>' . ACSCW_TEST_PAID . '</p>' );
t( '* oEmbed excerpt contains no paid body', false === strpos( $embed, ACSCW_TEST_PAID ) );

// feed body and REST content.rendered both pass through the_content
$feed = apply_filters( 'the_content', $paid_post->post_content );
t( '* feed body contains no paid body', false === strpos( $feed, ACSCW_TEST_PAID ) );

// nested case
t( 'a nested Paywall does not leak the paid body', false === strpos( $nested_html, ACSCW_TEST_PAID ) );

// the other direction: not over-removing
t( 'a hand-written excerpt is not rewritten', '著者が書いた抜粋。' === $manual_excerpt, $manual_excerpt );
t( "a purchaser's excerpt is not rewritten", '' === $paid_excerpt );

The point of the RSS and oEmbed assertions is that they deliberately pass in a string containing the paid body as input, so the moment a filter lets it through, the test fails. Re-running this harness while writing the article gave PASS 160 / FAIL 0 (PHP 8.5.7, CLI).

You have to write just as many assertions on the "not over-removing" side (hand-written excerpts, purchasers' excerpts) as on the "does not leak" side — otherwise an implementation that blanks everything turns the suite green.

Summary

In a block editor paywall, the paid body remains in post_content as plain text. The place to protect is not save time but every output route
Dropping the blocks in the_content at priority 5 (before do_blocks) handles four routes at once: single page, auto excerpt, feed body, and REST content.rendered
The remaining the_excerpt_rss / the_excerpt_embed do not pass through the_content, so close them individually. Do not blank excerpts — rebuild them from the free portion
Fail closed when the post ID is unavailable or the block API is missing. Forget the compatibility array of old block names and only old posts leak
Write verification in pairs, "does not leak" and "does not over-remove", and feed in input containing the paid body so a pass-through is detected

A CSS blur or a JS truncation is not protection as long as the body is in the response. Remove it from the response first, then draw the box — do it in that order and missing routes become mechanically detectable too.

I publish verification records and related plugins on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/wp-paywall-paid-content-leak-paths

wc_get_products() Silently Ignores meta_query: When Your Test Double Is Better Behaved Than the Implementation

ACS Developer — Mon, 14 Sep 2026 13:37:38 +0000

868 unit tests passed and the purchase flow was still broken in production: wc_get_products() silently drops meta_query, and my test stub was politely honoring an argument the real function ignores.

I built a WooCommerce integration plugin, got all 868 unit tests passing, and took it to a real environment (WordPress 7.1 + WooCommerce 11.0.1) — where the purchase flow was broken at its root. The cause was not weak tests. It was that the test double was better behaved than the implementation.

This article records that single incident on a measured basis: symptoms, cause, fix, and a regression test that provably fails against the pre-fix code.

Symptom: they paid, and access was never granted

The plugin sells individual articles and handles tips (donations) by mapping them to WooCommerce products. A product is created per amount, and the article side looks up the matching product by amount and hands it to checkout.

Three behaviors showed up in the real environment:

Tip products all resolve to the same product, regardless of amount
A first-time purchase of a paid article resolves to a tip product instead of the paid-article product
As a result, readers who pay are never granted access

Payment itself succeeds. The order is created. But the product ID the granting logic looks at is wrong, so buyers cannot read the content they bought. For a paid product this is the worst possible failure mode, and it does not surface until someone actually buys.

Cause: `wc_get_products()` does not look at `meta_query`

The product resolution code looked like this — just fetch one product by the price meta _acscw_price.

// before
$products = wc_get_products( [
    'status'     => 'publish',
    'limit'      => 1,
    'meta_query' => [
        [
            'key'   => '_acscw_price',
            'value' => (string) $price,
        ],
    ],
] );

$product = $products ? $products[0] : null;

wc_get_products() goes through WC_Product_Query, and WC_Product_Data_Store_CPT::query() builds WP_Query arguments only from the query vars it knows about. meta_query is not in that mapping table, so it is dropped silently — no error, no warning.

The query that actually executes is therefore just "one published product". So any amount returns the same single product, and all three symptoms appear at once. Nearby there was also code that permanently cached an unvalidated fallback result, which locked the misresolution in place and made it worse.

The essence is that an argument gets discarded silently, and this is easy to hit if you touch the wc_get_*() family with a WP_Query mindset.

Fix: use `WP_Query`, or register it on the data store filter

The shortest fix is switching to WP_Query. meta_query reliably applies, and since IDs are all you need, specify fields and no_found_rows too.

// after
$query = new WP_Query( [
    'post_type'      => 'product',
    'post_status'    => 'publish',
    'posts_per_page' => 1,
    'fields'         => 'ids',
    'no_found_rows'  => true,
    'meta_query'     => [
        [
            'key'   => '_acscw_price',
            'value' => (string) $price,
        ],
    ],
] );

$product_id = $query->posts ? (int) $query->posts[0] : 0;
$product    = $product_id ? wc_get_product( $product_id ) : null;

If you want to keep the wc_get_products() interface, translate a custom query var into WP_Query arguments through the data store filter.

add_filter(
    'woocommerce_product_data_store_cpt_get_products_query',
    function ( $wp_query_args, $query_vars ) {
        if ( isset( $query_vars['acscw_price'] ) && '' !== $query_vars['acscw_price'] ) {
            $wp_query_args['meta_query'][] = [
                'key'   => '_acscw_price',
                'value' => (string) $query_vars['acscw_price'],
            ];
        }
        return $wp_query_args;
    },
    10,
    2
);

// the caller uses the custom argument name (never passes meta_query)
$products = wc_get_products( [
    'status'      => 'publish',
    'limit'       => 1,
    'acscw_price' => $price,
] );

Either is fine, but practically speaking it is worth memorizing that the one thing that does not work is passing meta_query straight into wc_get_products().

Why 868 tests sailed right past it

This is the real subject. My tests run on a lightweight shim plus a real SQLite database harness, without booting a real WordPress, and at that point 5 suites (phases 2–6) totaling 868 assertions were all passing. None of them caught the bug above.

The reason is in the stub implementation.

// the stub, before (excerpt)
function wc_get_products( array $args ) {
    $products = TestStore::products();

    if ( ! empty( $args['meta_query'] ) ) {
        // the real wc_get_products() never looks at this
        $products = TestStore::filter_by_meta( $products, $args['meta_query'] );
    }

    return array_slice( $products, 0, $args['limit'] ?? count( $products ) );
}

When I wrote the stub, I assumed meta_query was "an argument that is obviously supported everywhere in WordPress" and implemented it faithfully. The real function ignores the argument; the stub dutifully interpreted it. When a test double is kinder than the real thing, code that only breaks in production sails through green.

As the countermeasure I moved the stub closer to real behavior and made it refuse to silently accept unsupported arguments.

// the stub, after (excerpt)
function wc_get_products( array $args ) {
    // allow only the query vars the real function supports
    $supported = [ 'status', 'type', 'limit', 'offset', 'orderby', 'order', 'return', 'sku', 'category' ];
    $unknown   = array_diff( array_keys( $args ), $supported );

    if ( $unknown ) {
        throw new RuntimeException(
            'wc_get_products() silently drops: ' . implode( ', ', $unknown )
        );
    }

    return array_slice( TestStore::products( $args ), 0, $args['limit'] ?? -1 );
}

What the real thing drops silently, the test drops loudly. Making the stub stricter exactly where behavior is ambiguous lets you catch this class of accident before it reaches a real environment.

Confirming the test fails against the old code

I added regression tests alongside the fix, but adding a test does not tell you whether that test actually catches this bug. So I mechanically verified that the new tests definitely FAIL against the pre-fix code.

// added regression test (excerpt)
$a = acscw_resolve_product_for_price( 300 );
$b = acscw_resolve_product_for_price( 500 );

assert_true( $a > 0 && $b > 0, 'no product resolves for the price' );
assert_not_equals( $a, $b, 'different prices resolve to the same product ID' );

The procedure is simple: a script reverts the fix commit back to the old implementation, then re-runs the harness. The measurements:

# with the fix reverted
harness-v3-phase3 : PASS 91  FAIL 65

# with the fix restored
harness-v3-phase3 : PASS 156 FAIL 0
(868 assertions PASS / 0 FAIL across all phases)

65 tests fail. So this regression suite really does catch the bug. Conversely, if reverting produces 0 failures, the test is verifying nothing. I think a new test's validity can only be established by that round trip.

Summary

Passing meta_query to wc_get_products() is ignored without an error. Use WP_Query, or translate a custom query var through woocommerce_product_data_store_cpt_get_products_query
When a test double is better behaved than the implementation, code that only breaks in production passes everything. Keep stubs within "what the real thing supports", and make unsupported arguments throw
A regression test's value is only settled once you confirm it fails when you revert the fix (here: 65 failures → 0)

Putting off verification in a real environment turns green tests from reassurance into merely not having checked which of the stub and the implementation is right. I caught this before shipping, but given that it is the kind of defect that stays invisible until someone buys something, it was worth reordering the process.

I publish verification records and related plugins on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/wc-get-products-meta-query-ignored

LISTENing but Connection Reset by Peer: A SQLite Connection Leak That Exhausted 255 of 256 File Descriptors

ACS Developer — Mon, 14 Sep 2026 13:32:07 +0000

A long-running local web UI kept its port in LISTEN but reset every HTTP connection: it had leaked 255 of its 256 allowed file descriptors, because with conn: on a sqlite3 connection commits but never closes.

A self-built local web UI with a job queue, kept resident by a macOS LaunchAgent, stopped opening one morning.

The awkward part was that it had not crashed. The process was running, the port was still LISTEN. Only HTTP would not go through. The last successful access had been about 36 hours earlier.

This article records how I chased that state down to file descriptor (FD) exhaustion, and from there to the behavior of sqlite3's context manager.

Symptoms

$ curl -sS http://127.0.0.1:8000/
curl: (56) Recv failure: Connection reset by peer

The same thing happened over a different route (access over VPN). It was route-independent, meaning the problem was on the process side, not the network side.

Meanwhile every naive health check was fine:

LaunchAgent job: running
Python process: alive
Target port: still LISTEN
Data volume: mounted

That trio — "the process is alive", "the port is open", "but connections are instantly reset" — is a sign to suspect not an application exception but a process that cannot acquire any more resources. If a TCP connection request cannot be accept()ed, the connection is reset without anything appearing in the application log.

Counting the culprit

So I counted the FDs the process was holding.

# total FD count for the process
lsof -p 780 | wc -l

# what is it holding, by kind
lsof -p 780 | awk '{print $NF}' | sort | uniq -c | sort -rn | head

The result was unambiguous.

Held object	Count
`queue.db`	122
`queue.db-wal`	121
Other (sockets etc.)	remainder
Total	255

And the limit for this process:

$ launchctl limit maxfiles
maxfiles    256            unlimited

255 / 256. Not one to spare. A socket for a new HTTP connection cannot be created, so the connection is reset before it is ever accept()ed. From curl's point of view, Connection reset by peer; from the application's point of view, nothing happened at all. That also explains the empty log.

SQLite in WAL mode opens both the main file and the -wal file per connection, which is why you get 122 against 121 — an almost 1:1 pair. That symmetry was a very readable fingerprint for "N connections are leaking".

Cause: `with conn:` does not close

Here is what was leaking.

# Before
def db():
    conn = sqlite3.connect(DB_PATH)
    conn.row_factory = sqlite3.Row
    return conn

# caller
with db() as conn:
    conn.execute("UPDATE jobs SET state = ? WHERE id = ?", (state, job_id))

with db() as conn: looks exactly like with open() for a file, so it feels like it closes. But the context manager on sqlite3.Connection only takes care of the transaction: commit() on normal exit, rollback() on exception. It does not close().

So the code above adds one connection per request. Sometimes GC reclaims them, but you cannot count on that in code that keeps references or in a long-lived process. Hitting it a few times locally shows no problem at all; it only surfaces when the process has been resident for days. That is why it took about 36 hours from the last good access to the failure being noticed.

The fix

Wrap it with contextlib.contextmanager and always close in finally.

import sqlite3
import contextlib

@contextlib.contextmanager
def db():
    conn = sqlite3.connect(DB_PATH)
    conn.row_factory = sqlite3.Row
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise
    finally:
        conn.close()

Callers keep writing with db() as conn: unchanged. Only the behavior changes.

There was one more instance of the same oversight. In the code that opens a log file at worker startup and hands it to a child process, the parent's FD was never closed. I changed that to with open(...) as f: so it closes immediately. The child already holds a duplicated FD from fork/exec, so writes continue after the parent closes.

For testing, I also made the DB path overridable by environment variable, so I could verify the lifecycle without disturbing the real service queue.

DB_PATH = os.environ.get("APP_DB_PATH", DEFAULT_DB_PATH)

Confirming "it is fixed" with numbers

FD leaks are easy to believe you have fixed when you have not. I confirmed by delta, not by eye.

1. 300 iterations in a test environment

With the DB path swapped out, I wrote a test that calls the state API 300 times. Result: FD delta of 3 or less (within the noise of running the test itself). Before the fix, this would have added close to 300.

2. 120 iterations against the real service

At a moment with zero in-flight jobs, I restarted the service and did the same thing against the real thing.

BEFORE=$(lsof -p "$PID" | wc -l)
for i in $(seq 1 120); do curl -s -o /dev/null "http://127.0.0.1:8000/api/state"; done
AFTER=$(lsof -p "$PID" | wc -l)
echo "$BEFORE -> $AFTER"

The result was 23 -> 23. Across 120 requests the FD total did not move by one. After the restart both routes returned HTTP 200, and I confirmed no loss of stored data (2 registered profiles, 4 history entries, 4 outputs).

Lessons

When the process is alive and only connections die, suspect resource limits first. Chasing the application log turns up nothing. A failure to accept() happens at a layer below your application
A resident process's limit is not your interactive shell's limit. Looking at ulimit -n in your own shell is meaningless. Here, the LaunchAgent's soft maxfiles was 256, and that was the real ceiling. Check the value applied to the process itself
with conn: is a transaction boundary, not a resource boundary. Worth checking for connection-like objects with context managers generally, not just sqlite3
Verifying a leak fix comes down to "call it N times and measure the delta". Once you can show 23 -> 23 as a measurement, there is no room left for opinion

Raising the limit (increasing maxfiles) is also an option, but it only extends the time to exhaustion; as long as the leak exists you end up back in the same place. Count, close, then measure a delta of zero — that order was the reliable one.

I publish verification records and related tools on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/sqlite-connection-leak-launchd-maxfiles

An LLM API Returned 4.17 Million Characters: Using MD5 Fingerprints to Prove It Was Duplication, Not Generation

ACS Developer — Mon, 14 Sep 2026 13:26:36 +0000

A draft that should have been 3,000 characters came back at 4,169,336 — and splitting it by section and fingerprinting with MD5 proved that only 28 sections were ever generated and the other 2,037 were byte-identical copies.

In a WordPress AI article generation plugin I built, a draft that should have been around 3,000 characters was saved at 4,169,336 characters. I only noticed because the estimated reading time displayed as 8,712 minutes.

It is tempting to write this off as "the LLM ran away and generated the same thing over and over", but that does not add up with the billed token count. This article starts from that contradiction, uses section splitting and MD5 fingerprint analysis to separate "characters that were generated" from "characters that were copied", and ends with physical evidence that the cause was not on the client side.

The same technique lets you triage "the output looks weird" around LLM APIs with numbers instead of impressions.

Both of my first two hypotheses were wrong

When I first saw the failure, I formed two hypotheses. Both suspected the client side — my own code.

A bug in the continuation loop's stop condition — mishandling finishReason, failing to stop continuation requests, and accumulating the results
Duplicate appending in the body concatenation — appending the entire text so far on every chunk merge

Both plausible. That is in fact where I started. But the measured values in the API console made both look doubtful.

Here is what one runaway request actually measured:

Request count  : 7
Input tokens   : 13.86k
Output tokens  : 19.55k

19.55k output tokens is at most a few tens of thousands of characters in Japanese. Nowhere near 4.17 million.

If hypothesis 1 (continuation loop) were right, the request count would be far larger; if hypothesis 2 (duplicate appending) were right, output tokens would stay normal while only the body ballooned — the latter was still alive. So I went to look at what was actually saved.

Triage 1: How many times was it saved?

A WordPress post exposes date and modified if you hit the REST API read-only. If an appending loop had been running, the post would have been updated multiple times.

curl -s "https://example.com/wp-json/wp/v2/posts/<ID>?context=edit" \
  | jq '{date, modified, len: (.content.raw | length)}'

{
  "date": "2026-08-22T21:42:43",
  "modified": "2026-08-22T21:42:43",
  "len": 4169336
}

date and modified match exactly, down to the second. In other words, 4.17 million characters were written by a single wp_insert_post(). There is no appending loop and no continuation-fetch loop. Hypothesis 2 dies here.

I also audited the entire plugin code and found not a single place that concatenates a response body onto itself. The story that the client simply saved what it received became much stronger.

Still, that is only a claim of innocence. To prove it, I had to look inside those 4.17 million characters.

Triage 2: Split into sections and take MD5 hashes

This is the heart of it. Reading an enormous generated text by eye is impossible, but if you split it into structural units and hash them, repetition patterns become obvious at a glance.

The article body was divided by h2 headings, so I split on h2, took an MD5 fingerprint of each section, and counted occurrences.

import hashlib
import re
from collections import Counter

with open("draft.html", encoding="utf-8") as f:
    body = f.read()

# split on h2 boundaries (keep anything before the first heading as one section)
sections = re.split(r"(?=<h2)", body)
sections = [s for s in sections if s.strip()]

fingerprints = [hashlib.md5(s.encode("utf-8")).hexdigest() for s in sections]
counter = Counter(fingerprints)

print(f"Total sections  : {len(sections)}")
print(f"Unique sections : {len(counter)}")
for rank, (digest, n) in enumerate(counter.most_common(3), 1):
    idx = fingerprints.index(digest)
    print(f"  #{rank}  {n:>4} times  section length {len(sections[idx]):>5}")

The output looked like this (the actual digest values are environment-specific, so they are replaced with ranks):

Total sections  : 2065
Unique sections : 28
  #1   432 times  section length approx. 1700 chars
  #2   431 times  section length approx. 1700 chars
  #3   357 times  section length approx. 1700 chars

Of 2,065 sections, only 28 are unique. The most frequent section appears 432 times, and since the MD5 values match, those are completely identical strings — not one byte different.

Looking at the ordering as well, the pattern was "section 0 → one new section → fixed suffix", repeating aperiodically about 350 times. Because it is not periodic, it is also not a simple copy-paste loop.

Why this is provably "not generation"

This is the decisive part. The generation parameter was temperature = 0.7.

With sampling at temperature 0.7, the probability that 1,700 characters (several hundred tokens) reproduce byte-for-byte identically 432 times is effectively zero. When you sample each token from a probability distribution, repeating the same topic will always produce variation in wording. And indeed, the varied repetitions did appear as different hashes among the 28.

So the 4.17 million characters decompose like this:

Category	Reality
Actually generated	28 unique sections ≒ 19.55k tokens
Not generated	the remaining 2,037 sections = byte-level copies of those 28

And "the 28 sections that were actually generated" lines up cleanly with the 19.55k output tokens measured in the API console. The contradiction from the opening resolves here: billing and quota management were only counting the generated part, and the duplication happened downstream of it.

The conclusion is that the model generated a normal amount, and the layer that assembles and returns the response duplicated the same sections roughly 2,000 times, returning a body of about 4.2MB. As for the maxOutputTokens = 32768 cap itself, a reproduction test with the cap lowered to 50/200 confirmed that MAX_TOKENS stops correctly, so the generation limit was being respected. What was broken was not generation but response assembly.

I am not asserting that this behavior is permanent (it is one occurrence observed in my environment). What matters is that the client side could be cleared by physical evidence rather than by claims about the code.

The fix is not retrying — it is rejecting at the door

When the cause is not on your side, you cannot fix it by changing your code. All you can do is avoid ingesting a broken response. So I put three safety valves in place, all of them before parsing and before saving.

// (1) cut off by raw response size (before JSON parsing)
if ( strlen( $raw_body ) > 1500000 ) {
    return new WP_Error( 'acs_oversized_response',
        'Response size is abnormal (' . number_format( strlen( $raw_body ) ) . ' bytes). Generation aborted.' );
}

// (2) cut off by body length (before wp_insert_post)
if ( mb_strlen( $content ) > 100000 ) {
    return new WP_Error( 'acs_oversized_content',
        'Body is abnormally long, so saving was aborted (' . number_format( mb_strlen( $content ) ) . ' chars).' );
}

// (3) detect repeated identical headings
preg_match_all( '/<h2[^>]*>(.*?)<\/h2>/s', $content, $m );
$dupes = array_filter( array_count_values( array_map( 'trim', $m[1] ) ),
    static fn( $n ) => $n >= 3 );
if ( $dupes ) {
    return new WP_Error( 'acs_repeated_headings',
        'Repeated identical headings detected, so saving was aborted.' );
}

Three design points:

Put (1) before JSON parsing. Handing a 4.2MB body to json_decode() first wastes memory and time. Byte length is the only indicator available before reading, so make it the first gate
Do not swallow failures silently. All three surface as explicit errors. Quietly truncating turns into a different failure — "for some reason the article is short"
Be selective about retrying. Only a failure inside a batch generation gets one automatic retry; there is no unconditional retry, because it may just fetch the same broken response again

For verification I used the actual 4.17-million-character data from the real incident as input. All 7 safety-valve tests passed and the 4 existing regression tests passed too. Normal generation against the real API completed in 43.1 seconds / 10,283 characters, and under a long-form condition 49.5 seconds / 6,948 characters. I also raised the timeout from 90 to 180 seconds (a long-form measurement stretched to 176.5 seconds).

The procedure you can take away

When you hit an output anomaly in a product built on an LLM API, this order gets you there fast:

Cross-check metadata against the console measurements — do request count and input/output tokens match the artifact in front of you, even by order of magnitude? If not, that is your shortest lead
Pin down how many times it was saved — if the timestamps (date / modified and friends) match, you can discard the whole family of append-loop hypotheses at once
Split into structural units and hash them — headings, paragraphs, chunks, anything. Just counting unique values and the top occurrence count separates "generation variance" from "byte duplication"
Cross-check against temperature — if temperature is non-zero and yet you see many byte-exact matches, that is not generation
If the cause is outside, reject at the door instead of fixing — drop it at three layers (size, length, structure), before parsing and before saving

Step 3 is the one that really works. It converts "I feel like it's writing the same thing over and over" into 28 unique / 2,065 total / 432 max occurrences, which is very hard to argue with. Discarding two hypotheses took a 20-line script.

I publish verification records and related tools on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/llm-response-duplication-md5-forensics

Never Name a zsh Loop Variable path: Three Deploy-Verification Traps That Looked Like Outages

ACS Developer — Mon, 14 Sep 2026 13:17:27 +0000

In one day of post-deploy verification I hit three failures that all looked like "production is broken" and none of which were: zsh's tied path array destroying PATH, percent-encoded URLs compared against raw ones, and plain propagation delay.

I run a static site generator, and after each deploy a zsh script mechanically verifies that "all 10 public surfaces return HTTP 200, and their contents match the local build output (dist)".

Running that verification for a day, I hit three traps of completely different natures: a bug in the verification script, a bug in the comparison logic, and propagation delay on the delivery side. Every one of them could have led straight to the wrong conclusion — "production is broken" — so I am writing them down.

Trap 1: Using zsh's reserved `path` array as a loop variable

I had named the loop variable of a hash-comparison loop path without thinking.

# the broken code
for path in dist/index.html dist/rss.xml; do
  shasum -a 256 "$path"
done

Here is what you get:

zsh:1: command not found: shasum
zsh:1: command not found: shasum

The files exist, but now the command cannot be found.

The cause is zsh's tied array. In zsh, path is typed and linked to PATH; rewriting one rewrites the other.

$ typeset -p path
typeset -aT PATH path=( /opt/homebrew/bin /usr/local/bin /usr/bin /bin ... )

The -T in typeset -aT PATH path is what does it. In other words, for path in ... is not an assignment to an ordinary loop variable — it is a rewrite of PATH. Printing $PATH inside the loop made it obvious:

path=dist/index.html
PATH=dist/index.html

PATH now has exactly one entry, dist/index.html, so every subsequent command lookup fails. The fix is just renaming the variable.

# the fixed code
for file_path in dist/index.html dist/rss.xml; do
  shasum -a 256 "$file_path"
done

Command lookup survives and each file's SHA-256 prints normally.

path is not the only tied name. cdpath, fpath, manpath, module_path and others are also linked to their lowercase array counterparts. In zsh scripts you can avoid all of this simply by not using bare lowercase common nouns as loop variables (use file_path, target, url, and so on).

If you use one inside a function, declaring it local closes the scope so that PATH is restored after the function returns. But PATH is still broken while the function runs, so it is not a real workaround.

check() {
  local path                      # PATH outside the function is protected
  for path in a b; do :; done     # but you cannot call commands in here
}

The nasty part is that the error message is command not found: shasum. If you start investigating it as a path or filename problem, you will take a long detour. When commands suddenly go missing in zsh, suspect the name of the loop variable you just wrote — that was the shortest route.

Trap 2: Comparing URL-encoded Japanese without decoding it

The internal-link check extracts links from the production HTML and matches them against the generated files in dist. In that comparison, URLs containing Japanese tags produced six false positives (reported as broken links) in one batch.

The hrefs in the production HTML are percent-encoded, while the local file name list was still raw Japanese. As strings they obviously do not match.

production HTML :  /tags/%E7%B1%B3%E5%9B%BD%E7%B5%8C%E6%B8%88/
local           :  /tags/米国経済/

After decoding and re-comparing, all 21 unique internal links returned HTTP 200 and were fine. What was broken was the verification script, not production.

On sites that put Japanese tags or categories into URLs, you must normalize before comparing (decode, or encode both sides the same way). When several broken links suddenly appear at once, it pays to suspect the comparison code before suspecting the site.

Trap 3: Almost classifying a post-deploy 404 as an outage

On the first check immediately after the deploy completed, I saw:

New article page: HTTP 404
Markdown mirror: HTTP 404
Aggregate surfaces such as the top page and indexes: HTTP 200, but showing the old content

This is the classic look of "delivery is broken". It is tempting to panic and push again or purge caches, but I did not push again; I waited 20 seconds and re-verified, and all 10 surfaces returned HTTP 200 with SHA-256 matching the local dist. It was simply propagation delay.

If you push again in that moment, a false causality — "I fixed it, so it got fixed" — gets recorded, and you repeat the pointless operation every time after that. The right design is for the verification script to wait a fixed interval and retry after the first failure, and report only the surfaces that still fail as an incident.

What went back into the verification script

Based on those three, post-deploy verification settled into this shape:

Never use zsh tied-array names such as path as loop variables (make it a fixed review checklist item)
Always decode before comparing URLs. Treat encoding differences as "not normalized", not "does not match"
Do not treat the first HTTP failure as final; wait, then re-check
Make the pass condition "HTTP 200 and SHA-256 matching the local dist", not just "HTTP 200"

Item 4 in particular pays off. If a 200 alone is enough, the old version can keep being served and still pass; only by checking the content hash can you say it was actually deployed. In trap 3 the aggregate surfaces were exactly that — "200 with old content".

Summary

zsh's path is a reserved array tied to PATH. Using it as a loop variable breaks command lookup, and the symptom shows up as command not found
Comparing Japanese URLs without normalizing the encoding difference mass-produces false positives
A 404 or stale content right after a deploy may be propagation delay. Wait and re-check before doing anything else
Do not make "HTTP 200" the only pass condition. Deployment is only confirmed once the content hash matches

All three would have landed on the wrong conclusion — "production broke" — if left alone. It comes down to the obvious point that the verification script is itself something that needs verifying.

I also publish measurement records around verification and automation on ACS Developer.

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/zsh-path-array-deploy-verify-pitfalls

Undefined type Float8_e4m3fn on Apple Silicon: BF16 and GGUF Workarounds for FP8 Models

ACS Developer — Mon, 14 Sep 2026 13:16:11 +0000

Two FP8 image models crashed with Undefined type Float8_e4m3fn on an Apple Silicon Mac, and each needed a different fix — a BF16 swap for one, a GGUF build (plus a loader patch) for the other — with measured generation times for both.

When you load an FP8-quantized image generation model on an Apple Silicon Mac (MPS backend), it can stop with this error:

Undefined type Float8_e4m3fn

I hit this on a 32GB unified-memory Apple Silicon machine (M5) with a ComfyUI-based setup, on two separate models — FLUX.2 and Krea 2 Turbo — and worked around each in a different way, taking measurements afterwards. This article is that record.

Case 1 (FLUX.2): solved by swapping only the main model for the BF16 build
Case 2 (Krea 2 Turbo): no realistic BF16 option, so I switched to a GGUF-quantized build (plus a patch for the loader's architecture tag)

What is actually happening

FP8 (float8_e4m3fn) is usually distributed as a quantization format aimed at NVIDIA GPUs, and the MPS backend does not support arithmetic on that dtype. In my environment, loading the official FLUX.2 FP8 build (flux-2-klein-4b.safetensors, about 4.07GB) stopped with Undefined type Float8_e4m3fn the moment it entered the first linear layer.

The key point is that this is not "out of memory" — it is an unsupported dtype. Lowering the resolution or cutting the step count will not fix it. FP8 builds look attractive because the files are small, but on a Mac you have to plan your setup on the assumption that they simply will not run.

Case 1: Swap only the main model for BF16 (FLUX.2)

FLUX.2 ships an official BF16 build, so I replaced only the diffusion model itself with the BF16 version. That was a single file; everything else was reused as-is.

Role	File	Size
Diffusion model	`flux-2-klein-4b.safetensors` (BF16 build)	approx. 7.75GB
Text encoder	`qwen3vl_4b_fp8_scaled.safetensors`	approx. 5.24GB
VAE	`flux2-vae.safetensors`	approx. 0.34GB

What is interesting is that the fp8_scaled text encoder ran on MPS without any change. Not every file with "FP8" in its name is doomed; what breaks is the place where a float8_e4m3fn tensor actually enters an operation. Reading which layer the error came from, and keeping the swap as small as possible, also turned out to be the better choice for disk space (deleting the failed FP8 model reclaimed about 4GB).

Measurements after the BF16 swap (32GB machine, MPS)

Task	Resolution	Measured time	Estimated peak memory
Plain t2i generation	512x512	20.2 s	approx. 25.1GiB
Edit with 1 reference image	512x512	30.3 s	—
Generation with 2 reference images	800x1408	90.2 s	approx. 27.2GiB

BF16 files are roughly twice the size of FP8, but with 32GB of unified memory even an 800x1408 generation with reference images stayed at a peak of about 27GiB. On a 16GB machine this setup will be rough — in that case the GGUF route below is the main option.

Case 2: Switch to a GGUF-quantized build (Krea 2 Turbo)

The FP8 build of Krea 2 Turbo failed with the same Float8_e4m3fn error. Here, loading BF16 outright was too heavy, so I moved to a GGUF-quantized build (Q6_K, 10.6GB), which ran stably on MPS.

GGUF is a quantization format that came out of the LLM world, but it can be used for image generation models through ComfyUI-GGUF. For a Mac that cannot use FP8, it is the realistic way to "keep the file small and still run".

The trap: mismatched GGUF architecture tags

With community-distributed GGUF files (for example krea2_raw_bf16-Q5_1.gguf), the architecture tag inside the GGUF is a custom value (krea2), and the ComfyUI-GGUF loader rejects it as an unknown architecture.

I solved this with a local patch that adds a one-line alias to the architecture check in ComfyUI-GGUF/loader.py (treating krea2 as a compatible architecture name). The idea looks like this:

# near the architecture check in loader.py (conceptual code)
if arch == "krea2":
    arch = "qwen_image"  # alias-resolve to a compatible architecture

Two caveats:

A git pull wipes the patch. If a GGUF that worked yesterday suddenly fails to load after a custom node update, suspect this first.
Spoofing the tag is only valid when the contents really are a compatible architecture. If the model is genuinely something else, it will break, as you would expect.

Decision guide

Undefined type Float8_e4m3fn is an unsupported dtype. Resolution and step tweaks will not fix it
If an official BF16 build exists, swapping only the component that errors is the shortest path (the surrounding files often keep working unchanged)
If BF16 is too heavy for your memory, a GGUF-quantized build is the practical answer. At the Q6_K level I could confirm the quality is usable
If the loader rejects your GGUF, check the architecture tag. Manage the patch on the assumption that updates will erase it

I also published a model-agnostic version of this triage procedure (a four-way classification of the errors, what to record, and a decision table) on ACS Developer: Apple Silicon FP8 model errors and BF16 alternatives, measured

Originally published in Japanese on Zenn: https://zenn.dev/acs_developer/articles/apple-silicon-mps-float8-e4m3fn-workaround

DEV Community: ACS Developer

You Can Upload but Not Edit: YouTube Data API Scopes and publishAt Scheduled Publishing

What I wanted

Trip 1: the youtube.upload scope only lets you upload

Trip 2: which channel does that token belong to?

Implementation: resumable upload and publishAt

Trip 3: killing off "I thought it was scheduled"

Stopping double uploads

Summary

Drop session_start() from Your Paywall: HMAC-Signed Cookies and Single-Use Recovery Links

Premise: sessions cannot coexist with page caching

1. A signed cookie with no server-side state

Keep the signing key separate from the framework's salt

2. You cannot put a nonce in a single-use link

Do not leave the token in the URL

3. Do not turn the recovery form into an email existence oracle

Rate limiting on two axes, with no raw values in the key

4. Verification results

Summary

Guarding the_content Is Not Enough: Six Routes That Leak Paid Content in a WordPress Paywall

Premise: the paid body stays in post_content as plain text

The six exposure routes

Net 1: drop the blocks in the_content at priority 5

Nesting: drop the whole parent

The hole in net 1: excerpts do not always pass through the_content

Fail closed in two places

Net 2: check again in the render callback

Verification: assert that nothing leaked

Summary

wc_get_products() Silently Ignores meta_query: When Your Test Double Is Better Behaved Than the Implementation

Symptom: they paid, and access was never granted

Cause: wc_get_products() does not look at meta_query

Fix: use WP_Query, or register it on the data store filter

Why 868 tests sailed right past it

Confirming the test fails against the old code

Summary

LISTENing but Connection Reset by Peer: A SQLite Connection Leak That Exhausted 255 of 256 File Descriptors

Symptoms

Counting the culprit

Cause: with conn: does not close

The fix

Confirming "it is fixed" with numbers

Lessons

An LLM API Returned 4.17 Million Characters: Using MD5 Fingerprints to Prove It Was Duplication, Not Generation

Both of my first two hypotheses were wrong

Triage 1: How many times was it saved?

Triage 2: Split into sections and take MD5 hashes

Why this is provably "not generation"

The fix is not retrying — it is rejecting at the door

The procedure you can take away

Never Name a zsh Loop Variable path: Three Deploy-Verification Traps That Looked Like Outages

Trap 1: Using zsh's reserved path array as a loop variable

Trap 2: Comparing URL-encoded Japanese without decoding it

Trap 3: Almost classifying a post-deploy 404 as an outage

What went back into the verification script

Summary

Undefined type Float8_e4m3fn on Apple Silicon: BF16 and GGUF Workarounds for FP8 Models

What is actually happening

Case 1: Swap only the main model for BF16 (FLUX.2)

Measurements after the BF16 swap (32GB machine, MPS)

Case 2: Switch to a GGUF-quantized build (Krea 2 Turbo)

The trap: mismatched GGUF architecture tags

Decision guide

Trip 1: the `youtube.upload` scope only lets you upload

Implementation: resumable upload and `publishAt`

Premise: the paid body stays in `post_content` as plain text

Net 1: drop the blocks in `the_content` at priority 5

The hole in net 1: excerpts do not always pass through `the_content`

Cause: `wc_get_products()` does not look at `meta_query`

Fix: use `WP_Query`, or register it on the data store filter

Cause: `with conn:` does not close

Trap 1: Using zsh's reserved `path` array as a loop variable