coreapi not respecting context timeouts

[philwinder]

Checklist

• This is a bug report, not a question. Ask questions on discuss.ipfs.io.
• I have searched on the issue tracker for my bug.
• I am running the latest kubo version or have an issue updating.

Installation method

built from source

Version

v0.17.0

Config

No response

Description

When using the IPFS HTTP RPC (/api/v0) client, we set timeouts in the context in the normal go way. But when using the coreapi it doesn’t look like timeouts are respected in the same way. For example, when you do a stat with the coreapi, (I belieive) it goes directly to the filesystem to do that stat, therefore there’s no delay and no timeout applied. Is that correct?

In that case, I guess there should still be a timeout somewhere because even when you’re using coreapi it might just take too long to get an object over IPFS. So the question is, where should that timeout now reside?

Context: this test is failing because no timeout is evaluated (and therefore it doesn’t timeout). Previously, when using the HTTP client, the stat would timeout when you set the timeout to 0.

cc: @Jorropo

[BigLep]

@Jorropo : what are the next steps on this one?

[Jorropo]

I have looked this up, the context is correctly plumbed all the way through and flatfs is the culprit: https://github.com/ipfs/go-ds-flatfs/blob/3b1c91bc3097ec7702347d8a419269ce88e450b8/flatfs.go#L651-L667

The impact is that if you already have the blocks locally and you are using flatfs to store them, we do not check the context and try to run requests until completion.

However things where we really care about context is for high latency operations (bitswap, remote datastore, ...) all of thoses work fine (actually I didn't checked the S3 code).

Given that there is no support for context.Context in golang's std os package (what we use to read and write to files).
I think this is a WONTFIX because most workarounds are costy (at least until golang/go#57928 is not fixed).

There is also a world where we do the dirty:

select {
case <-ctx.Done():
  return nil, ctx.Error()
default:
}

In flatfs operations, but I don't really like that either. That only solve the issue if you happen to call with an already terminated context, if the context would expire while the read or write is happening (and not before), then it does nothing.

---

More read about the subject: golang/go#20280

[BigLep]

Closing given @Jorropo comments in #9532 (comment)