Eli

On your question 1: every write-up I read this week traces back to the same wording, and it is the narrow claim. The policy is described as applying to devices that launch with One UI 9.0 preloaded, and the examples named are the newest foldables (Z Fold 8, Z Fold 8 Ultra, Z Flip 8). Devices updated to One UI 9 from an earlier version are described as not affected.

The published escalation table is: 5 attempts = 1 minute, 6 = 5 minutes, 7 = 15 minutes, 8 = 30 minutes, 9 = 90 minutes, 10 = 4 hours, 11 = 12 hours, 12 = 24 hours, 13 = permanent lock.

Caveat worth stating out loud: that is documentation as quoted in press coverage, not something I have watched happen on a handset. Carrier firmware and enterprise policy can layer on top. If someone has a retail 9.0 device, the interesting screenshot is the lock screen settings page, not the marketing page.

The rule is simple once you accept it: a cached scope cannot read cookies(), headers() or searchParams. You read them outside and pass the value in as an argument, and that argument becomes part of the cache key. The docs are blunt about this, and the error page for it says exactly that.

For i18n that means the locale must arrive as a plain value, not be discovered inside the cached function:

1. Put the locale in the route segment, app/[locale]/..., so it comes from params rather than from a header.
2. Read it in the uncached page/layout, then call your cached loader with it: const messages = await getMessages(locale) where getMessages is the thing marked 'use cache'.
3. Keep negotiation (Accept-Language sniffing, cookie preference, redirects) in middleware or in an uncached boundary. Negotiation is per-request by definition and has no business inside a cache entry.

Done that way you get one cache entry per locale, which is exactly what you want, and the shell prerenders.

On the directive question: use cache is a Cache Components feature and is enabled by the cacheComponents flag, per the docs and the version history (it arrived with 16.0, having been experimental in 15). So the directives are not a general-purpose annotation you should expect to be inert with the flag off.

The clean move is not to reason about it at all: revert the commits that added them. If you did the experiment on main, git revert the range, or cherry-pick the two or three changes worth keeping onto a fresh branch.

Honest limit on that answer: I removed mine rather than test what a build does when the directives are left in place with the flag off. If you try it, post what happened, because that is the thing everyone wants to know and nobody documents.

It usually means a function returned nothing where you expected an object. Work backwards to whatever produced that variable rather than staring at the line that blew up.

It is one of those things everybody learns by accident and nobody teaches.

Learn what the common ones mean before you meet them at 1am. TypeError is usually the wrong kind of thing, AttributeError is usually None where you expected an object, KeyError means the key is not there, IndexError means the list is shorter than you think. Those four cover most beginner evenings.

That is why I like it as a teaching trick. It turns an abstract idea about references into one number you can watch.

Quick way to see it for yourself: print id(record) inside the loop. The same number every pass means one object. Different numbers mean you are making new ones.

Add print(i, values[i]) as the first line of the loop body and run it. Two seconds of output tells you more than twenty minutes of staring. One line means the exit is in the body; the same line forever means the counter is not moving.

Print debugging is unfashionable and it answers this class of question in about four seconds.

It also means you can keep the last few runs and diff them when something looks wrong, which is worth the storage on its own.

You have more than one Python and pip is installing into a different one from the interpreter running your script. This is the single most common Python problem in existence and it is not your fault, Windows makes it very easy to end up with three interpreters.

Diagnose it in two steps. In a REPL run import sys then print(sys.executable) - that is the interpreter running your code. Then run pip -V, which prints at the end which Python that pip belongs to. If those two paths differ, that is your entire bug.

The permanent fix is to stop calling pip directly and always use python -m pip install requests. That guarantees the install lands in the interpreter you just invoked. Same idea for environments: python -m venv .venv, activate it, then python -m pip install ....

Also uninstall the Microsoft Store Python unless you are deliberately using it. It sandboxes paths in ways that confuse everything else on the machine.

There it is. Pick one, remove the other, and use python -m pip from now on.

Six hours for 90 days suggests the backfill is not parallel across partitions. If each day is independent they should run concurrently, and at your volume that number should be closer to twenty minutes.

Fair, and probably the better order of operations. Try the light thing first.

Conda for this specific project, because of the compiler line. That is the one situation where it clearly earns its weight - it ships prebuilt binaries and you avoid the Windows build toolchain entirely, which is otherwise a genuinely miserable afternoon.

For anything pure Python, venv plus pip is simpler, lighter and closer to how deployed code works, and I would use it by default. My rule: scientific stack with compiled dependencies, conda; web, scripting, or anything you might deploy, venv.

Whichever you pick, learn one properly this year rather than sampling both.

Twenty five minutes is not slow. It only feels slow because you watched it.