This change sounds like a good candidate for being shipped with 1.6 — behind a TAPI flag if necessary. What do you think?

I believe this can be merged without TAPI, because the old behavior is to not commit anything at all. Therefore the data requests will be unsolved until a majority of miners update, and then it will just work as expected.

It is true that we won't have a guarantee that these data requests will be solved until the next TAPI update, which ensures that miners have updated, but I believe nothing will break if this change is merged without TAPI.

It is true that we won't have a guarantee that these data requests will be solved until the next TAPI update, which ensures that miners have updated, but I believe nothing will break if this change is merged without TAPI.

I'm just fine with that approach. Thanks!

I don't think it is a good idea to special-case HTTP/403 errors, because many APIs return 404 or 401 instead.

I don't think it is a good idea to special-case HTTP/403 errors, because many APIs return 404 or 401 instead.

Yeah right, either HTTP/401 or HTTP/403 errors in one single source would be sufficient condition for not commiting to a data request. Data requests relying on a majority of private API sources returning 404 error codes would just be resolved as HttpError { code: 404 }.

@tmpolaczyk shall we rebase and merge this onto 1.6?

@tmpolaczyk shall we rebase and merge this onto 1.6?

Done