[Registry Publish] Non existent nodes

[robinjhuang]

Currently, we create the node_version row first before the node pack zip is actually uploaded. This can result in a node version that has no zip file if the file upload fails afterwards. Modify the CLI to delete the node version if this happens.

[james03160927]

Hi @robinjhuang, even if we include the logic to delete the node version in the CLI, there is always the possibility of orphaned node versions due to various failures (e.g., network issues, service outages, hardware failures), which could result in the node version being in the incorrect status. This issue could be addressed through the proposed node version status update. I've modified the proposal to account for this scenario. Here’s the high-level overview:

Updated Node Version Status Definitions

Here is the high-level transition flow for the node version status

1. (new) INIT: Initial state when a user initiates the node version upload process. The system hasn't yet confirmed whether the node version has been uploaded to cloud storage.
2. (change) Pending → Uploaded: The node version has been successfully uploaded to cloud storage.
3. Flagged: Security vulnerabilities detected, requiring human review.
4. (new) Security-Pass: Passed security scanning (previously referred to as "active").
5. Banned: Explicitly disallowed due to security or functional issues.
6. (new) Non-Functional: Node-pack-extractor runs ComfyUI in a sandbox environment and installs the new custom node version to extract node-level data. A cloud build process failure indicates the node is not functioning properly. This status also confirms that node-level data extraction was successful.
7. Active: Fully validated and ready for use.
8. Deleted: Node version has been removed.