I submitted my community node package n8n-nodes-nordstellar for verification through the Creator Portal, and the automated pre-check fails with only a generic message pointing me to the community package scanner (see error below).
However, running exactly that command locally (scanner v0.27.0) against the current latest version 0.1.3 passes all checks: Provenance check passed for n8n-nodes-nordstellar@0.1.3 Downloaded n8n-nodes-nordstellar@0.1.3 Analyzed n8n-nodes-nordstellar@0.1.3 Package n8n-nodes-nordstellar@0.1.3 has passed all security checks
Package details:
npm: https://www.npmjs.com/package/n8n-nodes-nordstellar (latest: 0.1.3)
GitHub (public): GitHub - NordStellar/n8n-nodes-nordstellar · GitHub, tagged v0.1.3 matching npm latest
Scaffolded and built with the official n8n-node CLI; lint (n8n-node lint) passes
Published via GitHub Actions with npm trusted publishing (OIDC) + provenance
Starter-conventional layout (top-level credentials/ + nodes/), correctly-cased filenames, no runtime dependencies
One detail that may be relevant: after my first submission, I unpublished versions 0.1.0 and 0.1.1 from npm (within npm’s 72-hour window; 0.1.2 and 0.1.3 remain published). If the pre-check pinned one of the unpublished versions instead of the current latest, that could explain the mismatch. I re-triggered the checks after publishing 0.1.3 and it failed again with the same generic message.
Could someone from the verification team check what the pre-check actually reports for my submission, or re-point it at 0.1.3?
What is the error message (if any)?
Your submission has failed the automatic vetting process. Please address the below issues and try again
Changes required to your node package
Some of the tests have failed, please run npx @n8n/scan-community-package n8n-nodes-nordstellar for more details.
Since npx @n8n/scan-community-package n8n-nodes-nordstellar passes locally on v0.1.3, it does sound like the Creator Portal might be validating a cached or older package version rather than the current latest. The unpublished 0.1.0/0.1.1 versions could definitely be worth investigating.
Another thing I’d ask the verification team to check is whether the Creator Portal is pulling the correct npm dist-tag (latest) and whether there’s any cache that needs to be refreshed for your submission. If everything checks out locally, this feels more like a verification pipeline issue than a problem with your package.
First off, kudos on publishing a Blueprint to the community – that’s a fantastic contribution! It’s clear you know your way around n8n, especially after tackling the Reliability Architect (FINAL EXAM) and understanding performance and deployment.
This issue with your
n8n-nodes-nordstellar
package failing the Creator Portal pre-check while passing locally is a classic case of “works on my machine, but the cloud says no.”
The Problem: You’re correctly pointing out the discrepancy: your local
npx @n8n/scan-community-package
passes all checks for
n8n-nodes-nordstellar@0.1.3
, but the Creator Portal’s automated system reports a generic failure. Your hypothesis about the unpublished versions (0.1.0, 0.1.1) is very strong and likely the culprit.
Why This Might Be Happening:
Caching or Stale Indexing: The Creator Portal’s verification system might have initially tried to resolve your package’s versions shortly after you published 0.1.0 or 0.1.1. If it cached this information or created an internal index, it might be attempting to download or verify against those now-unpublished versions.
npm unpublish
makes a version permanently unavailable, so if the system tries to fetch it, it will fail, leading to the generic “tests have failed” message.
Version Resolution Logic: Even after re-triggering, if the system’s logic for determining the “latest” or “correct” version to scan isn’t perfectly aligned with the real-time npm registry status, it could still be trying to hit a non-existent version. This is especially true if there’s a slight delay or a specific strategy (e.g., picking the numerically lowest available version from an initial scan) that inadvertently targeted your now-removed versions.
What You Can Do (and What’s Needed):
Unfortunately, this isn’t something you can fix by adjusting your node’s code or an n8n workflow. This requires intervention from the n8n team who manages the Creator Portal.
Direct Contact/Support Ticket: Since you’ve already re-triggered and confirmed your local environment is clean, the next step is to directly contact the n8n team responsible for community node verification.
If you’re already in a direct communication channel (e.g., email or Discord DM related to your submission): Provide them with the details you’ve shared here, emphasizing your hypothesis about the unpublished versions (0.1.0, 0.1.1) and requesting they:
Manually check the exact error logs for your submission in their pre-check system.
Ensure their system is targeting
n8n-nodes-nordstellar@0.1.3
for verification.
Potentially clear any cached package version information related to your submission.
If not, and you’re interacting via the Creator Portal UI: Look for a “Contact Support” or “Report an Issue” option within the portal itself. If that’s not available, reaching out through the official n8n community forums (e.g., in a “Node Development” or “Creator Portal” section) would be a good next step to get the attention of the right team members.
You’ve done all the right troubleshooting steps on your end, @Admin. This seems to be an edge case in the verification system itself due to the timing of your unpublishing.
Keep up the great work on
n8n-nodes-nordstellar
! Hopefully, the team can get this resolved quickly for you.
@MantasG-nordsec I have manually moved your node to the next stage, It looks like the issue is with the NPM release pipeline for the verification tool.
Provenance check passed for n8n-nodes-nordstellar@0.1.3