https://pantsbuild.org/ logo
Join Slack
Powered by
I have a repo with some custom pants plugins and I...
# plugins
d
I have a repo with some custom pants plugins and I'm seeing some bizarre behavior after making a change that I don't think should have caused any failures. I have three rules A, B, and C. B uses 
await Get(ProcessResult, CRequest....)
to call rule 
C
. 
C
has dependencies on other rules, but they're all rules that are provided by pants; none of them are custom rules from our repo. Until today, 
A
didn't depend on any other rules. Everything has been working quite well. Today, I updated 
A
to depend on 
C
in the same way that 
B
depends on 
C
. However, this is resulting in rule graph errors anytime I run any pants commands. I'll attach the stacktrace in the thread, but the main error message is this: 
ValueError: Encountered 225 rule graph errors:
. However, the exact number of alleged rule graph errors is random; rerunning the same command potentially produces a different number of rule graph errors than the previous run even if I don't make any changes. If I comment out the 
await Get(ProcessResult, CRequest...)
line in 
A
, the rule graph errors go away and pants is happy again. I've tried adding the 
-ldebug --print-stacktrace
flags, but this doesn't result in any additional helpful output being produced. Any ideas on what's happening here? I'm really confused as (1) calling this rule from 
B
is fine but causes everything to start on fire when I try to use it from 
A
(2) nothing is calling this function yet. Is pants scanning the source code of each rule function in order to infer dependencies?
Here's that stacktrace:
Copy code
File "/Users/stephenhopper/Library/Caches/nce/cf6c1988edaa5d40bbf385ae79a75e6d2abba937217d1b672c71eaf0ea495bcd/bindings/venvs/2.18.0/lib/python3.9/site-packages/pants/pantsd/pants_daemon_core.py", line 176, in prepare
    self._initialize(
  File "/Users/stephenhopper/Library/Caches/nce/cf6c1988edaa5d40bbf385ae79a75e6d2abba937217d1b672c71eaf0ea495bcd/bindings/venvs/2.18.0/lib/python3.9/site-packages/pants/pantsd/pants_daemon_core.py", line 119, in _initialize
    raise e
  File "/Users/stephenhopper/Library/Caches/nce/cf6c1988edaa5d40bbf385ae79a75e6d2abba937217d1b672c71eaf0ea495bcd/bindings/venvs/2.18.0/lib/python3.9/site-packages/pants/pantsd/pants_daemon_core.py", line 109, in _initialize
    self._scheduler = EngineInitializer.setup_graph(
  File "/Users/stephenhopper/Library/Caches/nce/cf6c1988edaa5d40bbf385ae79a75e6d2abba937217d1b672c71eaf0ea495bcd/bindings/venvs/2.18.0/lib/python3.9/site-packages/pants/init/engine_initializer.py", line 198, in setup_graph
    return EngineInitializer.setup_graph_extended(
  File "/Users/stephenhopper/Library/Caches/nce/cf6c1988edaa5d40bbf385ae79a75e6d2abba937217d1b672c71eaf0ea495bcd/bindings/venvs/2.18.0/lib/python3.9/site-packages/pants/init/engine_initializer.py", line 345, in setup_graph_extended
    scheduler = Scheduler(
  File "/Users/stephenhopper/Library/Caches/nce/cf6c1988edaa5d40bbf385ae79a75e6d2abba937217d1b672c71eaf0ea495bcd/bindings/venvs/2.18.0/lib/python3.9/site-packages/pants/engine/internals/scheduler.py", line 226, in __init__
    self._py_scheduler = native_engine.scheduler_create(
ValueError: Encountered 225 rule graph errors:
c
The graph errors that comes after is more interesting in this case.. 🙂 however, it’s rarely easy to read them and see what the issue is, unfortunately. Running with 
-ltrace
may prove more insightful as you get a dot graph you can render which usually is more illustrative to look at to find the root cause.
g
If you read my post and thread right above yours I had a similar case triggered by a new edge creating a cycle.
What I did to debug it was simply removing Get calls from C until it worked, then investigated alternatives
d
however, it’s rarely easy to read them and see what the issue is, unfortunately
Exactly. This isn't the first time I've run into rule graph issues. It's always frustrating when it happens. I've never found the error message to be helpful. Especially in this case; it's claiming that ~250 things are broken which is misleading I've tried running with 
-ltrace
in the past, but generating the graphviz from that output took over an hour and wasn't helpful. I'll give that a shot for this particular problem though
@gorgeous-winter-99296 Thanks for the insights. I don't see how my change would create any kind of cycles as 
C
only has dependencies on things which are internal to pants / coming from other Python plugins. But I'll generate the graphviz and see if I can spot something awry
Okay, I think I found the issue. There were two other rules 
R1
and 
R2
. 
R1
was invoking 
R2
via 
Get(ProcessResult, {digest: Digest, req: R2Request})
R2
was invoking 
A
I moved 
digest: Digest
into the fields of 
R2Request
, so the call from 
R1
to 
R2
became this: 
Get(ProcessResult, R2Request, req)
Now everything is happy
I found the error thanks to 
-ltrace
as it pointed me in the general direction of 
R1
and 
R2
, but none of the actual error messages, stack traces, etc were actually helpful
I looked at that 
Get
with two parameters and seemed to recall reading something in the docs saying that was a bad practice
c
yea, rule graph errors is the single worst issue to run across with unhelpful diagnostics..
d
Is that 
dict
format for using 
Get
inside of a plugin still valid on 2.18? The docs seem to indicate that it's not valid anymore (see the "Why only one input" section). But this worked fine on 2.16 (and worked fine on 2.18 up until my aforementioned change to make 
A
call 
C
)
c
yea, still valid. it’s used extensively in pants.
that doc note has gone stale…
would love an issue about it, if you don’t mind writing a ticket: https://github.com/pantsbuild/pants/issues/new/choose 🙏
👍 1
3 Views
Open in Slack
PreviousNext
Powered by