Add failure reason in allocation_eligible.rs

[gusinacio]

Some errors and warns appear more than others. In general, I like the idea of having the reason why something is failing within the error message. Also, maybe some reason on how to fix them.

This error occurs when the gateway is trying to send receipts for an allocation ID that your indexer doesn't recognize as theirs.
It might be that the network subgraph is delayed, or indexer cannot query it and it's stuck with an older state.

We should be able to know if the subgraph is in an older state and let the user know that this might be the reason why it's failing.

[shiyasmohd]

@gusinacio So basically, we should be checking,

• If the network subgraph is lagging behind X blocks
  Before returning the error, and give a warning message, this might be the issue. Am I in the right direction?

[gusinacio]

Subgraphs should be treated as potential failures in the system. Most of the system relies on fresh data but sometimes data that is not so fresh still works.

What I want is to have a way for consumers of watchers to know:

• if there was an error in the last query of the function watcher

Also, subgraphs clients should return if the response return is delayed or not synced.

With this, in case a given function that relies on subgraph/watcher data returns an error, it can add information of the possible cause (failure of subgraph or delayed).

This might be two different issues or split in 2 PRs. Now that I thought about it, it's not that trivial to implement this. Just removed the good-first-issue tag.

[shiyasmohd]

@gusinacio Another question.
How do we define, delay of a subgraph? I mean, How much blocks should it be lagging to be defined as delay?
Another interesting thing is, synced field in indexingStatus doesn't actually mean, Subgraph is synced. It means, subgraph is synced once. So there is no value checking synced field

[gusinacio]

We know the latest response, we could add some information to check the _meta of the query and compare it against the previous query.

Another option is check the block timestamp against our local clock and verify if it's too old (more than 1 minute).