@dcaro the patch for T337903 already did something about this issue, but I was wondering if we'd sometime in the future attempt to build a system that sort of attempts to infer different errors and try to reword them to be maybe more explanatory. For example with the recent merge, trying to reproduce the scenario described in this issue with write only

Not Found for url: https://api.svc.tools.eqiad1.wikimedia.cloud:30003/builds/v1//build/wm-lol-buildpacks-pipelinerun-h8fvnnsoteu/logs

But I wonder if this is enough. Do you think there is a need have a system that can for example read the above error and reword it like

log for build wm-lol-buildpacks-pipelinerun-h8fvnnsoteu not found

But to get something like the above means having a way to handle all possible errors

In T336884#8933439, @Raymond_Ndibe wrote:

@dcaro the patch for T337903 already did something about this issue, but I was wondering if we'd sometime in the future attempt to build a system that sort of attempts to infer different errors and try to reword them to be maybe more explanatory. For example with the recent merge, trying to reproduce the scenario described in this issue with write only

Not Found for url: https://api.svc.tools.eqiad1.wikimedia.cloud:30003/builds/v1//build/wm-lol-buildpacks-pipelinerun-h8fvnnsoteu/logs

But I wonder if this is enough. Do you think there is a need have a system that can for example read the above error and reword it like

log for build wm-lol-buildpacks-pipelinerun-h8fvnnsoteu not found

But to get something like the above means having a way to handle all possible errors

Yep, that's why generic errors might be misleading.

I think we should handle the most common cases (404 when specifying a build, etc.) and keep the "generic" as a fallback.

For example on that error, it would be better to reply with something like:

Build wm-lol-buildpacks-pipelinerun-h8fvnnsoteu not found

as that's the main reason why the logs endpoint would not be found (except if the api url configuration is bad or similar).

for this logs endpoint, for example, are there any other reason(s) 404 Client Error can be raised? I'm a bit weary of giving all incidence of 404 or say 500 HTTP error the same string explanation. It's tempting to try and see what the error message itself says. I guess my question can be better phrased as: Do we prefer to have these very specific error messages at the risk of mislabeling/misreporting some errors?

In T336884#8945666, @Raymond_Ndibe wrote:

for this logs endpoint, for example, are there any other reason(s) 404 Client Error can be raised? I'm a bit weary of giving all incidence of 404 or say 500 HTTP error the same string explanation. It's tempting to try and see what the error message itself says. I guess my question can be better phrased as: Do we prefer to have these very specific error messages at the risk of mislabeling/misreporting some errors?

Currently there's 3 cases that we explicitly return 404:

• If we did not find any pipelineruns matching the build id
• If we found more than one pipeline run matching that id
• If we failed to list any pipelineruns (k8s returning an error when doing a pipelinerun list)

Using a generated client would solve partially these issues as it would automatically parse the return values and return the right content, but as we are rewriting it in python I think that a safe strategy would be quite similar to what we were doing before:

• Try to parse the content of the error as {"message": "somestring"}
  • If it worked, print only the message in a nice way (that is for errors we explicitly handle)
  • If it did not work, print the generic 404 error (this is for errors we don't handle, ex. if the url is malformed)

this should be fixed when we merge https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-cli/-/merge_requests/6

closing this because it was resolved by https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-cli/-/merge_requests/6