validation "race" condition between <meta> and <meta>.install packages?

[Leif-W]

Not sure why, but I am often seeing these packages such as nodejs or notepadplusplus fail to validate, with the sole reason being that the corresponding .install file was not found, despite it existing and being validated moments later. Then the main package gets stuck in limbo for days or weeks. Why is the validation system failing like this? Why are packages set up in a way that leads to repeated failure? Why not just use one package name instead of a dummy package and the actual package? If an .install of the same base name is detected as a dependency, there should be a check if the package.install has been queued. If the package maintainer or automated script is submitting the .install afterwards because of "reasons" like sorted order, then the validation system should wait for the .install to be submitted. There should be queues, and callback hooks, and observers, to handle the cases when the .install is submitted later, or validates later. In the worst case, an absolutely dumb/naïve system should just have a retry with increasing intervals like 5 minutes, 15 minutes, 30 minutes, 1 hour, etc, and a retry count/max like 5 retries or something. Though perhaps simpler to implement and a fair short-term solution, it may yield excessive polling at scale. Keeping queues and callback hooks may be more complex to implement and use more memory, but it'd only run validation attempts when the dependency files are actually submitted and/or validated. This scenario of a single package with a single .install package should only result in a failure if there is an actual failure, not a series of avoidable failures ad nausea due to poor system design which ignores a recurring, foreseeable problem. What can be done to correct the validation system?

[gep13]

@Leif-W I am happy to be able to tell you that we recently made a change to the Chocolatey Community Repository infrastructure to make improvements in this area, as it was something that we were hearing from different places.

@Leif-W said... If an .install of the same base name is detected as a dependency, there should be a check if the package.install has been queued.

This is essentially what has been done, and as a result, we shouldn't see the issue that you are highlighting here.

[gep13]

Please let us know if you continue to see problems in this area.