Eye suddenly stops executing rules

[tpluscode]

I the API testing project, I found that when I run multiple test cases (and thus requests), there is a certain threshold which, when reached, suddenly stops

I thought it was related to simply running many processes with e:exec but a synthetic case did not work and I easily called curl 1000 times.

[josd]

I'm calling curl 10000 times (10 times more than you mentioned) in https://github.com/eyereasoner/eye/blob/master/reasoning/shell-command/query-10000.n3 and it nicely gives https://github.com/eyereasoner/eye/blob/master/reasoning/shell-command/query-10000-answer.n3

Could you give a concrete example showing that things are broken?

[tpluscode]

I need to investigate. I assumed that it was something related to child processes but I must have been wrong. So far I only have example too complex to be useful

[tpluscode]

Upon further investigation, maybe it is related to this trick you shared which prevents a rule from executing multiple times (to avoid side effects)

   # ... match ?req ...
 
  ({ ?req tuner:done true } false true) log:ifThenElseIn ?SCOPE .
  true log:becomes { ?req tuner:done true } .

I added a trace in the positive condition of this if statement and I found that with each matched instance of ?req, all those previously executed are evaluated over and over. At some point it looks like eye does not find an more rules to execute, prematurely...

[tpluscode]

I also find something else. In my specific example, I iterate over a paged hydra collection (a HTTP API). Each response includes a hydra:next link. Until the last page, that is. I match that link and dereference when it exists.

Here's the relevant code:

  ?req tuner:response ?res ; tuner:url ?page .

  (
    {
      ?body log:includes {
        <countries>!hydra:view hydra:next ?nextPage .
      } .
    }
    {
      ?body log:includes {
        <countries> hydra:view ?view .
        ?view hydra:next ?nextPage .
      } .
   
     (?view!log:localName ": " ?page!log:localName " => " ?nextPage!log:localName)!string:concatenation^log:trace .

      true log:becomes {
        <#fetchEntireCollection> <#fetch> ?nextPage
      }
    }
    {
      true log:becomes { <#fetchEntireCollection> earl:outcome earl:passed }
    }
  )!log:ifThenElseIn .

See I added that log:trace to see how the links are followed. Depending on page size it works or works until a certain point. If I set limit=50, it goes through the entire collection. But for example if I set it to limit=10 it breaks after this being logged

?_90858 TRACE "countries?limit=10&offset=40: countries?limit=10&offset=260 => countries?limit=10&offset=50"

So it looks like a wrong value for ?view is bound. As if the body from a previous request /countries?limit=10&offset=40 is taken instead of the expected countries?limit=10&offset=260. Could it be that blank nodes or variable identifiers are incorrectly reused at some point and stuff gets mixed up?

tl;dr; ?req tuner:response ?res is a backward rule which does

( "curl -s -X " ?method " '" ?endpoint "' -o " ?responseBodyFile )!string:concatenation!e:exec .

?responseBodyFile log:semantics ?res .

[josd]

Can you give the simplest possible concrete case that I can run and that shows that things are broken?

[tpluscode]

Yea, that's the hard part.

For now I could share the failing example if you are willing to run JS :)