Package not picked up by constructs.dev after major release

[ivanbarlog]

I have published new major version of my package @beesolve/lambda-bun-runtime today.

It was a huge jump from v1.14.0 to v2.103.14 - the reasoning behind this is that I want my package to be aligned with bun versioning.

2 - breaking change
103 - means major of bun + 100x minor of bun
14 - means patch of bun

Would you be able to help me list my new version of the package please?

[ivanbarlog]

Analysis of why v2.103.14 is not indexed

I reviewed the construct-hub source code to understand why this version is not being picked up. Here is what I found.

The package passes all automated filters

• jsii field is present in the npm registry metadata ✓
• peerDependencies includes aws-cdk-lib (a recognized construct framework package) ✓
• keywords includes cdk (in the CONSTRUCT_KEYWORDS allow-list) ✓
• MIT license (on the allowed list) ✓
• The version jump from 1.14.0 → 2.103.14 is not filtered anywhere in the follower or ingestion code ✓

Both versions are structurally identical from the perspective of isConstructLibrary() in npm-js-follower.lambda.ts.

Most likely causes

The indexing pipeline has three stages:

1. npm-js-follower.lambda.ts reads npm's CouchDB _changes feed sequentially using a stored marker (sequence ID). It also maintains a knownVersions map to avoid reprocessing. If the follower ran and failed to invoke stage-and-notify for this version (e.g. Lambda invocation error, transient timeout), the version may have been recorded in knownVersions without ever being staged.

2. stage-and-notify.lambda.ts downloads the tarball and stores it in S3. Could fail silently if the tarball download returned a non-200, non-404 status.

3. ingestion.lambda.ts extracts and validates the .jsii assembly. If the assembly fails loadAssemblyFromBuffer(), the package is dropped and only a CloudWatch InvalidAssembly metric is emitted — no error surfaced to the user.

The tarball is 34.6 MB (v1.14.0 was 37.5 MB and was indexed fine), so size is unlikely to be the issue.

Requested action

Could you please:

1. Check whether @beesolve/lambda-bun-runtime@2.103.14 appears in the knownVersions S3 file — if it does, it was seen but may not have been successfully ingested.
2. Manually trigger re-ingestion by invoking the re-stage-package-version Lambda with:

   { "name": "@beesolve/lambda-bun-runtime", "version": "2.103.14" }

3. If that doesn't resolve it, check CloudWatch logs for the ingestion Lambda for any InvalidAssembly or MismatchedIdentityRejections metric emissions around the time of publication.

Thank you for looking into this.