Dev Feed

Confirmed the above works as a direct devDependency in a repo using ESLint 8.56.0

Perhaps superceded by https://github.com/antfu/eslint-plugin-format. Not tested myself yet, but supports `dprint`

Just came across this too. Unfortunately chimes with other ESLint upgrades I've had to do in the past where lots of things seem to break.

On decrypting cookies set by one particular site (Goodreads.com), I got the following error: > RangeError: out of range index > at RangeError (native) > at decrypt (node_modules/chrome-cookies-secure/index.js:59:8) > at Statement.db.each.host (node_modules/chrome-cookies-secure/index.js:268:21) The offending line 59 is `final.copy(decoded, decoded.length - 1);`. Changing it to `final.copy(decoded, decoded.length ? decoded.length - 1 : 0);` (no longer assuming that the target buffer contains data) fixed the issue for me, though I don't know if that's the best solution.

Closing given inactivity, no other reports, and works on latest release.

@dopecodez a kind bump on this one

Release - Published

@zcdev It doesn't re-produce for my login on Goodreads.com. Apple Silicon, M4. However, the OP was most definitely not using Apple Silicon when he raised this issue. Still, I think given this issue's age this one can be closed cc @eloquence

It is indeed included in `3.0.1` - https://github.com/bertrandom/chrome-cookies-secure/releases/tag/v3.0.1 I will try and verify this once and for all this weekend, as I now have an Apple Silicon machine.

Yes, unintentional @dopecodez I've reverted those now.

Seems like a general AWS SDK issue in Lambda only. We get this for SecretsManager SDK. AI tooling recommends moving the instantiation inside the execution context, but that hasn't worked, which is very weird - that signals some underlying cache behaviour that we can't control outside of the execution context? None of our latency logs point to any kind of delay even close to 5 minutes: I'm working on high throughput, fast acting lambdas by design ~10-100ms. This is contributing about ~4,000 errors a week across our ecosystem out the moment. A real noise issue.

Same issue here with nocks that previously worked (v13) to intercept requests to AWS e.g. something pushing to S3. They fail on Nock 14 with a `NetConnectNotAllowedError: Nock: Disallowed net connect for...bucket.url` error. We only have `enableNetConnect(127.0.0.1)` for our suite to completely isolate all tests, but given we nock the AWS URLs I wouldn't expect this to hard error (and previously, it didn't).

Interesting point on OS. I'm running locally on `macOS`, but in the cloud on `ubuntu-latest`. Just had this come up again Github Action <img width="792" height="102" alt="Image" src="https://github.com/user-attachments/assets/552f5d4c-9f6e-4ba5-9420-495c2bdd1104" /> Local <img width="1324" height="69" alt="Image" src="https://github.com/user-attachments/assets/0888d130-0799-47ee-a53c-1526e4ccf863" />

Release - Published