Use Harper readonly mode for Next.js builds by cb1kenobi · Pull Request #41 · HarperFast/nextjs

cb1kenobi · 2026-05-01T21:40:30Z

Next.js uses child processes to generate static pages. When those pages reference Harper data, it will try to load those databases and error with:

Error: IO error: While lock file: /Users/chris/harper/database/data/LOCK: Resource temporarily unavailable opening database /Users/chris/harper/database/data
    at openRocksDatabase (../harper/resources/databases.ts:162:22)
    at readRocksMetaDb (../harper/resources/databases.ts:407:16)
    at getDatabases (../harper/resources/databases.ts:247:6)
    at database (../harper/resources/databases.ts:734:2)
    at table (../harper/resources/databases.ts:899:20)
    at Object.<anonymous> (../harper/security/auth.ts:27:27)

Harper has a new READONLY environment variable that will allow a RocksDB database to be opened by another process in read-only mode allowing the static pages to be generated.

kriszyp

I believe we need to (somehow) flush all the databases so the new process can "see" all the data.

cb1kenobi · 2026-05-02T00:01:42Z

I believe we need to (somehow) flush all the databases so the new process can "see" all the data.

plugin.ts imports 'harper' and runs on the thread that has write access to the database, so does Harper have any public API that will flush all databases?

kriszyp · 2026-05-02T02:01:19Z

plugin.ts imports 'harper' and runs on the thread that has write access to the database, so does Harper have any public API that will flush all databases?

No, I think we will need to add one.

Ethan-Arrowood · 2026-05-04T17:26:21Z


+	// Next.js generates static pages using child processes and only a single process can open the
+	// RocksDB databases, so force Harper to start in read-only mode
+	process.env.READONLY = 'true';


I'm surprised this wasn't prefixed with like ROCKSDB_ or HARPER_, but thats an upstream thing so no concern here.

Good idea! Sit tight.

Ethan-Arrowood · 2026-05-04T22:48:37Z

looks like this needs to wait until Harper is updated (or flushDatabases is added to the types export?)

cb1kenobi · 2026-05-05T02:50:30Z

Yeah, this PR needs to wait a little bit.

Ethan-Arrowood · 2026-05-13T16:27:54Z

I will convert to draft. Feel free to click the "Ready for Review" button when its good to go again.

cb1kenobi · 2026-05-13T16:36:44Z

We're just waiting on Harper 5.1.0 to ship.

socket-security · 2026-07-06T22:59:57Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
harper@5.0.9 ⏵ 5.1.23	^-34	^-12	⁺¹
@harperfast/integration-testing@0.3.1 ⏵ 0.7.0	^-1	⁺¹	⁺⁵
@types/node@20.19.39 ⏵ 26.1.1		⁺¹	⁺²
@playwright/test@1.59.1 ⏵ 1.62.0

View full report

socket-security · 2026-07-06T22:59:59Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Obfuscated code: npm `alasql` is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package-lock.json → `npm/harper@5.1.23` → `npm/alasql@4.17.3` ℹ Read more on: This package \| This alert \| What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/alasql@4.17.3`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm `alasql` is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package-lock.json → `npm/harper@5.1.23` → `npm/alasql@4.17.3` ℹ Read more on: This package \| This alert \| What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/alasql@4.17.3`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm `brace-expansion` is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package-lock.json → `npm/harper@5.1.23` → `npm/brace-expansion@5.0.4` ℹ Read more on: This package \| This alert \| What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/brace-expansion@5.0.4`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Includes npm shrinkwrap: npm `harper` Location: Package overview From: package-lock.json → `npm/harper@5.1.23` ℹ Read more on: This package \| This alert \| What is a shrinkwrap file? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should never use npm shrinkwrap files due to the dangers they pose. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/harper@5.1.23`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm `lmdb` is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package-lock.json → `npm/harper@5.1.23` → `npm/lmdb@3.5.6` ℹ Read more on: This package \| This alert \| What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/lmdb@3.5.6`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		High CVE: Picomatch has a ReDoS vulnerability via extglob quantifiers CVE: GHSA-c2c7-rcm5-vvqj Picomatch has a ReDoS vulnerability via extglob quantifiers (HIGH) Affected versions: >= 4.0.0 < 4.0.4; >= 3.0.0 < 3.0.2; < 2.3.2 Patched version: 2.3.2 From: package-lock.json → `npm/harper@5.1.23` → `npm/picomatch@2.3.1` ℹ Read more on: This package \| This alert \| What is a CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Remove or replace dependencies that include known high severity CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/picomatch@2.3.1`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm `robust-predicates` is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package-lock.json → `npm/harper@5.1.23` → `npm/robust-predicates@3.0.2` ℹ Read more on: This package \| This alert \| What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/robust-predicates@3.0.2`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Deprecated by its maintainer: npm `glob` Reason: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me From: package-lock.json → `npm/harper@5.1.23` → `npm/glob@7.2.3` ℹ Read more on: This package \| This alert \| What is a deprecated package? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Research the state of the package and determine if there are non-deprecated versions that can be used, or if it should be replaced with a new, supported solution. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/glob@7.2.3`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Deprecated by its maintainer: npm `inflight` Reason: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful. From: package-lock.json → `npm/harper@5.1.23` → `npm/inflight@1.0.6` ℹ Read more on: This package \| This alert \| What is a deprecated package? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Research the state of the package and determine if there are non-deprecated versions that can be used, or if it should be replaced with a new, supported solution. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/inflight@1.0.6`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Deprecated by its maintainer: npm `rimraf` Reason: Rimraf versions prior to v4 are no longer supported From: package-lock.json → `npm/harper@5.1.23` → `npm/rimraf@3.0.2` ℹ Read more on: This package \| This alert \| What is a deprecated package? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Research the state of the package and determine if there are non-deprecated versions that can be used, or if it should be replaced with a new, supported solution. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/rimraf@3.0.2`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

dawsontoth · 2026-07-23T14:32:14Z

@cb1kenobi think this is ready for a rebase? Do we have the right stuff published where this can happen?

cb1kenobi · 2026-07-23T17:03:14Z

@dawsontoth Updated the branch. Dropped Node.js 20 from test matrix, added Node.js 26. Had to update some dependencies to get the tests to run.

dawsontoth

Nice updates, though!

dawsontoth · 2026-07-23T17:06:54Z

@cb1kenobi if we get the GHA for release in before this one, then we can rest real releases.

cb1kenobi · 2026-07-23T17:16:07Z

Hmm, tests are failing due to "Error: ENOSPC: no space left on device". That can't be good.

dawsontoth

can bAIrber take a look at the failing integration tests?

Next.js uses child processes to generate static pages. When those pages reference Harper data, the child process tries to open the RocksDB databases and fails because only one process can hold the write lock at a time. Set HARPER_READONLY=true before Next.js spawns its build workers so they open Harper in read-only mode. Call flushDatabases() first so the child processes can see all committed data. Also: drop Node.js 20 from the CI test matrix, add Node.js 26; update dependencies; pass --install-links to npm install in install-fixtures.js to prevent circular symlinks (ELOOP / ENOSPC) caused by the file: protocol pointing back to the project root. Co-authored-by: Cursor <cursoragent@cursor.com>

@harperfast/nextjs 2.2.2 fixed the multi-thread build race (serializes the build across worker threads — HarperFast/nextjs#52), which is the only reason these templates shipped `prebuilt: true` + build-first scripts. Revert to the same server-side-build model as the other templates: - config.yaml: drop `prebuilt: true` (Harper builds on `harper run`/deploy). - scripts: `dev` → `harper dev .`, `start` → `harper run .`, `deploy` → `harper deploy_component ...` (no `next build &&` prefix). - bump `@harperfast/nextjs` to `^2.2.3` so the build-serialization fix is required. - README deploy note back to "Harper builds on the server, no local build". Verified on Harper 5.1.22 with @harperfast/nextjs 2.2.3: a fresh scaffold builds and serves multi-threaded via `harper run` (no prebuilt, no race) and the counter works. (Server code still uses the injected `tables`/`transaction` globals, not `import 'harper'` — that stays until HarperFast/nextjs#41 + #51 land.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

kriszyp

I think this would still be great to update and merge.

… in readonly mode HARPER_READONLY was set on process.env before calling next build so that Next.js child processes would open the Harper databases in read-only mode, avoiding the RocksDB lock conflict. However, it was never unset, so the server process itself also ran in read-only mode after the build completed, causing all Harper data queries to return nothing and pages to render blank. Save and restore the previous value in the finally block, matching the same pattern used for --expose-internals / process.execArgv. Co-authored-by: Cursor <cursoragent@cursor.com>

@harperfast/nextjs 2.2.2 fixed the multi-thread build race (serializes the build across worker threads — HarperFast/nextjs#52), which is the only reason these templates shipped `prebuilt: true` + build-first scripts. Revert to the same server-side-build model as the other templates: - config.yaml: drop `prebuilt: true` (Harper builds on `harper run`/deploy). - scripts: `dev` → `harper dev .`, `start` → `harper run .`, `deploy` → `harper deploy_component ...` (no `next build &&` prefix). - bump `@harperfast/nextjs` to `^2.2.3` so the build-serialization fix is required. - README deploy note back to "Harper builds on the server, no local build". Verified on Harper 5.1.22 with @harperfast/nextjs 2.2.3: a fresh scaffold builds and serves multi-threaded via `harper run` (no prebuilt, no race) and the counter works. (Server code still uses the injected `tables`/`transaction` globals, not `import 'harper'` — that stays until HarperFast/nextjs#41 + #51 land.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Co-authored-by: Cursor <cursoragent@cursor.com>

dawsontoth · 2026-07-27T17:27:48Z

The wait is over but the blocker moved — #60 targets this branch with the fix, plus the regression test this was missing.

@kriszyp @Ethan-Arrowood on "we'll need to add one" / "wait until Harper is updated": Harper already has flushDatabases, exported from index.ts since v5.1.0, and this branch pins 5.1.23. That's not what's failing.

What's failing is that components don't see the package's exports. Harper hands them a SyntheticModule built from a hardcoded allowlist — getHarperExports() in security/jsLoader.ts — and flushDatabases isn't on it (still isn't on main). A named import of a non-allowlisted symbol fails at link time, which kills the whole component:

SyntaxError: The requested module 'harper' does not provide an export named 'flushDatabases'

So @harperfast/nextjs never loads and no Next.js server starts. That's the current CI failure — 15 of 21 tests, and the 6 that pass only hit Harper's own operations/REST endpoints. It's visible only in the harper-logs-node-* artifacts; Playwright just reports missing elements, which is what makes it look like a Next.js problem. (The earlier ENOSPC was separate and is gone.)

HARPER_READONLY itself works fine in 5.1.23.

The flush does work today — under applications.moduleLoader: native, which bypasses the VM loader and resolves the real package. I verified this rather than assuming it: #60 runs the same fixture on both loaders. On the default loader the prerendered page renders an empty list while GET /Dog/rex returns Rex; under native the flush runs and the row is there. So the data-visibility problem Kris predicted is real and observable, and the flush is the thing that closes it.

Two follow-ups worth deciding:

Add flushDatabases to getHarperExports() so the flush works on the default loader. One line in harper. Happy to open it — say the word.
applications.moduleLoader: 'none' in our own integrationTests/fixture.ts doesn't mean "no sandbox". importScoped only skips the VM when the value is exactly 'native', so 'none' falls through to the most sandboxed loader. That's why CI hits the synthetic-module path at all. Left as-is in fix: unbreak integration tests on the read-only build branch, and cover it with a test #60 since changing it would alter what the suite covers, but it's probably not what was intended.

Also fixed in #60: --install-links was silently serving stale plugin code. It copies file:../.. rather than symlinking, and npm re-extracts that copy from its cache, so a rebuilt dist/ never reached the fixtures — install:fixtures now clears the copy and npm's hidden .package-lock.json.

🤖 Generated by Claude Code (Opus 5), reviewed by @dawsontoth

…er it with a test (#60) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

kriszyp

Great to see this coming together! Just a note in there about version requirements.
_{🤖 Reviewed with GPT 5.6}

…per data HARPER_READONLY and flushDatabases do not exist in Harper v5.0.x, so static generation that reads Harper data at build time requires v5.1+. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions · 2026-09-30T22:23:07Z

🎉 This PR is included in version 2.2.5 🎉

The release is available on:

Your semantic-release bot 📦🚀

…enerator (#71) * ci: lint the PR title, and match the analyzer's preset to the notes generator Squash is the only merge method here, and `squash_merge_commit_title` is COMMIT_OR_PR_TITLE, so for any PR with more than one commit the PR title becomes the subject of the commit that lands on main — and that subject is the only thing semantic-release reads. commitlint sees the commits inside the PR, which the squash then discards, so a title with no conventional type is a silent no-release. #41 shipped inside 2.2.5 with no note of its own, and #65 produced no release at all. A title check now runs on every pull request, including on `edited`, so a retitle re-checks. `@semantic-release/commit-analyzer` also carried no `preset` and so defaulted to `angular`, while the notes generator was explicitly `conventionalcommits`. The two now match. That is not only tidiness: `angular` does not recognise the `!` breaking-change shorthand, so `feat!: …` passed commitlint and then analysed as no release at all. Verified against both presets — `feat!:` is `none` under angular and `major` under conventionalcommits; every other type agrees. CONTRIBUTING gains the rules and a type-to-release table. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: record how squashing treats the two breaking-change forms The `!` is read only from the commit subject and a `BREAKING CHANGE:` footer only from the body, so under squash merging the bang counts in the PR title while the footer counts in a commit inside the PR. Both verified against the configured analyzer, including the shape GitHub actually produces. Also rewraps the section: the file keeps a paragraph on one line, and the first draft hard-wrapped at 100 columns. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: list every commit type the release config declares The no-release row named four of the seven. `style`, `build` and `ci` are declared in .releaserc.json too, and all three analyse as no release. Also notes that "none" is about triggering a release, not visibility: every declared type has its own section, so it still appears in the notes of whatever release it rides along in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore: drop the style and build note sections this repo does not use Both came in with the release config and neither is used here. Removing them from the presetConfig changes nothing about release types — both still analyse as no release — but such a commit is now hidden from the notes rather than given its own section. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

## [2.3.0](v2.2.5...v2.3.0) (2026-10-08) ### Features * back the `use cache` directive with Harper and persist per-entry cache lives ([#65](#65)) ([5bcd077](5bcd077)) ### Continuous Integration * lint the PR title, and match the analyzer's preset to the notes generator ([#71](#71)) ([9ebd026](9ebd026)), closes [#41](#41) [#65](#65)

cb1kenobi requested a review from a team May 1, 2026 21:40

cb1kenobi mentioned this pull request May 1, 2026

Read-only mode HarperFast/harper#450

Merged

kriszyp reviewed May 1, 2026

View reviewed changes

Ethan-Arrowood approved these changes May 4, 2026

View reviewed changes

Ethan-Arrowood marked this pull request as draft May 13, 2026 16:27

cb1kenobi marked this pull request as ready for review July 23, 2026 16:45

dawsontoth approved these changes Jul 23, 2026

View reviewed changes

dawsontoth requested changes Jul 23, 2026

View reviewed changes

cb1kenobi force-pushed the use-readonly branch from f86a4dd to cb58940 Compare July 23, 2026 21:00

cb1kenobi force-pushed the use-readonly branch from aec2e78 to 69d2349 Compare July 23, 2026 21:10

Merge branch 'main' into use-readonly

66a7ad7

dawsontoth mentioned this pull request Jul 24, 2026

feat(templates): add Next.js templates (JavaScript + TypeScript) HarperFast/create-harper#123

Merged

kriszyp reviewed Jul 27, 2026

View reviewed changes

chore: update @playwright/test to 1.62.0

2f254c8

Co-authored-by: Cursor <cursoragent@cursor.com>

cb1kenobi force-pushed the use-readonly branch from 6a1d061 to 2f254c8 Compare July 27, 2026 16:48

dawsontoth mentioned this pull request Jul 27, 2026

fix: unbreak integration tests on the read-only build branch, and cover it with a test #60

Merged

fix: unbreak integration tests on the read-only build branch, and cov…

501e089

…er it with a test (#60) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

cb1kenobi requested a review from dawsontoth July 27, 2026 17:33

dawsontoth approved these changes Jul 27, 2026

View reviewed changes

kriszyp approved these changes Jul 27, 2026

View reviewed changes

Comment thread package.json

cb1kenobi and others added 2 commits July 28, 2026 10:51

Merge branch 'main' into use-readonly

c09f356

cb1kenobi merged commit 982c14a into main Jul 28, 2026
7 checks passed

cb1kenobi deleted the use-readonly branch July 28, 2026 16:36

github-actions Bot added the released label Sep 30, 2026

Ethan-Arrowood mentioned this pull request Oct 7, 2026

ci: lint the PR title, and match the analyzer's preset to the notes generator #71

Merged

Conversation

cb1kenobi commented May 1, 2026

Uh oh!

kriszyp left a comment

Choose a reason for hiding this comment

Uh oh!

cb1kenobi commented May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kriszyp commented May 2, 2026

Uh oh!

Ethan-Arrowood May 4, 2026

Choose a reason for hiding this comment

Uh oh!

cb1kenobi May 4, 2026

Choose a reason for hiding this comment

Uh oh!

Ethan-Arrowood commented May 4, 2026

Uh oh!

cb1kenobi commented May 5, 2026

Uh oh!

Ethan-Arrowood commented May 13, 2026

Uh oh!

cb1kenobi commented May 13, 2026

Uh oh!

socket-security Bot commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

socket-security Bot commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dawsontoth commented Jul 23, 2026

Uh oh!

cb1kenobi commented Jul 23, 2026

Uh oh!

dawsontoth left a comment

Choose a reason for hiding this comment

Uh oh!

dawsontoth commented Jul 23, 2026

Uh oh!

cb1kenobi commented Jul 23, 2026

Uh oh!

dawsontoth left a comment

Choose a reason for hiding this comment

Uh oh!

kriszyp left a comment

Choose a reason for hiding this comment

Uh oh!

dawsontoth commented Jul 27, 2026

Uh oh!

kriszyp left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Sep 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

cb1kenobi commented May 2, 2026 •

edited

Loading

socket-security Bot commented Jul 6, 2026 •

edited

Loading

socket-security Bot commented Jul 6, 2026 •

edited

Loading

kriszyp left a comment •

edited

Loading