Consider Returning NAME_UNKNOWN errors for Blob GETs when Using the Database
Context
The V2 Blob GET, specifies the possibility of returning NAME_UNKNOWN
when the repository is not known to the registry.
Historically, the registry did not make the distinction between NAME_UNKNOWN
and BLOB_UNKNOWN
, it would take an extra call to backend storage to disambiguate these two scenarios and this is a heavily used endpoint.
When writing the database implementation, we chose to conform to the present behavior since downstream clients may not anticipate the NAME_UNKNOWN
error, even though it is specified in the API.
We had an incident where this ambiguity between NAME_UNKNOWN
and BLOB_UNKNOWN
increased the time to diagnose the root cause.
It may be worth investigating popular clients and seeing how they would handle this scenario.
It's important to note that a HEAD
request to this endpoint will typically be the first repository scoped request made to a given repository, and it will happen before the repository is created in the database, see the push request flow.
Therefore, we considered the risk of clients relying on the BLOB_UNKNOWN
value in this error message to proceeds, which would prevent them from pushing to new repositories, too high, and so we decided to match the behavior of the original implementation, rather than faithfully executing the spec.
We did not do an investigation into client implementations, as there are many possible clients, but it might be worth to challenge these assumptions so that we can have proper error messages for this endpoint.
Conclusion
After the investigation was completed, we agreed to not pursue this change right now as the risk of maintaining two registries with two behaviors for the same API outweighs the advantages we would get from this change.
We also concluded that we want the change present but only until we stop supporting the object storage metadata in the registry. See Return NAME_UNKNOWN errors for Blob GETs when U... (#1038) for future reference.