#UnknownDaggerError: Encountered an unknown error while requesting data via graphql

1 messages · Page 1 of 1 (latest)

wintry isle
#

I am getting a
UnknownDaggerError: Encountered an unknown error while requesting data via graphql
Code D101

I think it may be because we use dagger.io to run our E2E test pipeline and it took to long for dagger, is there a way to increase the timeout?

UnknownDaggerError: Encountered an unknown error while requesting data via graphql
    at compute 
    at async computeQuery 
    at async <anonymous> (/home/niebuhrd/RiderProjects/sba/pipelines/qa/build.mts:26:5)
    at async connect 
    at async Pipeline.run (/home/niebuhrd/RiderProjects/sba/pipelines/templates/dagger/pipeline.mts:16:5)
    at async <anonymous> (/home/niebuhrd/RiderProjects/sba/pipelines/qa/build.mts:5:1) {
  cause: TypeError: fetch failed
      at node:internal/deps/undici/undici:13178:13
      at async <anonymous> (/home/niebuhrd/RiderProjects/sba/pipelines/node_modules/graphql-request/src/legacy/helpers/runRequest.ts:191:10)
      at async runRequest (/home/niebuhrd/RiderProjects/sba/pipelines/node_modules/graphql-request/src/legacy/helpers/runRequest.ts:72:25)
      at async GraphQLClient.request (/home/niebuhrd/RiderProjects/sba/pipelines/node_modules/graphql-request/src/legacy/classes/GraphQLClient.ts:131:22)
      at async compute 
      at async computeQuery 
      at async File.export 
      at async Promise.all (index 3)
      at async materializeDotnetWorkflowResult (/home/niebuhrd/RiderProjects/sba/pipelines/qa/workflow.mts:112:5)
      at async <anonymous> (/home/niebuhrd/RiderProjects/sba/pipelines/qa/build.mts:26:5) {
    [cause]: HeadersTimeoutError: Headers Timeout Error
        at Timeout.onParserTimeout [as callback] (node:internal/deps/undici/undici:5975:32)
        at Timeout.onTimeout [as _onTimeout] (node:internal/deps/undici/undici:2356:17)
        at listOnTimeout (node:internal/timers:581:17)
        at process.processTimers (node:internal/timers:519:7) {
      code: 'UND_ERR_HEADERS_TIMEOUT'
    }
  },
  code: 'D101'
}
wintry isle
rancid bear
#

cc @rapid hamlet IIRC you're aware of some typescript graphql timeouts, correct?

rapid hamlet
#

Already fixed, will be out for the new release

rapid hamlet
#

I'll also work on a follow up to actually configure the timeout, I'm not sure how to do such thing for now though

rancid bear
#

that way @wintry isle might potentially get unblocked until the next release

rapid hamlet
#

Oh but I didn't set context directory for now in the TS Runtime, I'm not sure this would work..., since it's bundled inside the engine

#

I'm opening a PR right now to fix that

rancid bear
#

happy to 👀

rapid hamlet
#

I'll do a test right now

#

However it will not work

#

I need the codegen Go binary in the TS SDK source dir (I currently get it from the engine binary), but it's not available on GitHub

#

I wonder if I have a way to fetch it remotely somehow, any idea @rancid bear ?

#

In Python @frosty vapor hasn't that issue since he has a Python codegen 😦

#

I have an idea, but that would make the TS SDK much much slower (if it's not cached well), I check if /codegen is there, if not, I can create a go container, pull the dagger repo and compile the codegen bin

#

OR use a codegen module, if we have one?

#

But it's not working, I cannot download it 😦

#

It would be nice if we could call the codegen binary from the dagger-dev module

rancid bear
#

just wondering...

rapid hamlet
#

But these are private methodes 😦

#

If we could expose the builder, I could use it, but it would make the SDK so slow when fetching the codegen binary from the container

frosty vapor
#

I've actually been thinking for a while now that I'd love the codegen to be in an API call, instead of a CLI.

rapid hamlet
#

That would amazing

rancid bear
# rapid hamlet That would amazing

I see that'd be awesome. I think the only stopgap until the next release is to basically ask to @wintry isle do download the latest CLI and use that to get the latest code generation. You can do that by calling curl -fsSL https://dl.dagger.io/dagger/install.sh | DAGGER_COMMIT=$COMMIT sh

frosty vapor
#

The codegen bin is a separate cli.

rain river
rancid bear
rancid bear
wintry isle
rapid hamlet
rapid hamlet
rain river
#

Hey @wintry isle is the code you are working on public? We are trying to verify a fix but could use a few more projects to test with

wintry isle
#

hey @rapid hamlet and @rain river sorry i was on vacation

i just tried the most recent commit (e3f7b552d4fba1ce169b048c7e94d14aed658d64) and unfortunately i still get this error:

UnknownDaggerError: Encountered an unknown error while requesting data via graphql
    at compute )
    at async file:///home/niebuhrd/RiderProjects/sba/pipelines/node_modules/@dagger.io/dagger/dist/api/utils.js:70:31
    ... 3 lines matching cause stack trace ...
    at async File.export 
    at async Promise.all (index 3)
    at async materializeDotnetWorkflowResult (/home/niebuhrd/RiderProjects/sba/pipelines/qa/workflow.mts:112:5)
    at async <anonymous> (/home/niebuhrd/RiderProjects/sba/pipelines/qa/build.mts:32:5)
    at async connect 
  cause: TypeError: fetch failed
      at node:internal/deps/undici/undici:13178:13
      at async <anonymous> (/home/niebuhrd/RiderProjects/sba/pipelines/node_modules/graphql-request/src/legacy/helpers/runRequest.ts:191:10)
      at async runRequest (/home/niebuhrd/RiderProjects/sba/pipelines/node_modules/graphql-request/src/legacy/helpers/runRequest.ts:72:25)
      at async GraphQLClient.request (/home/niebuhrd/RiderProjects/sba/pipelines/node_modules/graphql-request/src/legacy/classes/GraphQLClient.ts:131:22)
      at async compute 
      at async 
      at async Promise.all (index 1)
      at async computeNestedQuery 
      at async computeQuery 
      at async File.export 
    [cause]: HeadersTimeoutError: Headers Timeout Error
        at Timeout.onParserTimeout [as callback] (node:internal/deps/undici/undici:5975:32)
        at Timeout.onTimeout [as _onTimeout] (node:internal/deps/undici/undici:2356:17)
        at listOnTimeout (node:internal/timers:581:17)
        at process.processTimers (node:internal/timers:519:7) {
      code: 'UND_ERR_HEADERS_TIMEOUT'
    }
  },
  code: 'D101'
}
#

and the project is not public, sorry

rancid bear
#

hmm.. this is quite strange.. I don't seem to be able to repro with the latest commit in main. @wintry isle mind checking if this pipeline triggers the same issue to you?

  @func()
  test(): Container {
    return dag.container().from("alpine:latest").withExec(["sleep", "6m"]);
  }

and then dagger call test osync

#

that pipeline succeded for me

image.png
wintry isle
#

i will try to create a minimum repro

wintry isle
wintry isle
rancid bear
#

What version of Dagger do you have in your package.json?

wintry isle
#

"devDependencies": {
"@dagger.io/dagger": "0.13.1",
"@septh/ts-run": "^1.3.0",
"@types/node": "^20.14.2",
"typescript": "^5.4.5"
},

rancid bear
#

You can't upgrade the 0.13.3 as the latest release doesn't work. We'll be releasing a new Hotfix this week ASAP

wintry isle
#

ooh okay ❤️ thanks 🙂

wintry isle
rancid bear
#

@wintry isle if you migrate your code to use dagger functions and use the latest main dagger CLI, you shouldn't experience this issue

wintry isle
#

i will push it to github so you can test it out on your end

wintry isle
rancid bear
wintry isle
#

trying with 0.13.3 cli now

wintry isle
rancid bear
wintry isle
#

also added a dagger run example to the github branch so now you have both in the same location

rain river
#

@rancid bear FYI - we consistently ran into this issue last week even running on main and trying a lot of different things.

@rapid hamlet I think you mentioned you were going to look into this some more?

rancid bear
rapid hamlet
#

I'll try on his repo

rapid hamlet
#

Ok so with that PR, it's not crashing after 5 minutes, it's still running I'm waiting for it to complete

Screenshot_2024-10-08_at_11.33.14.png
#

Still running after 12 minutes

Screenshot_2024-10-08_at_11.39.38.png
#

All good

Screenshot_2024-10-08_at_11.49.03.png
#

So #8576 may be the fix

hidden fox
#

Approved the fix - @wintry isle would you be able to try again (sorry), using the latest main commit once that one is merged?

wintry isle
#

sure, will try 🙂

#

@hidden fox can confirm running over 5minutes now

#

buuut now its taking much longer than expected, when I run the dotnet test command on its own its taking exactly 6min, but when running the dagger call function its running much longer

#

nevermind now it ran for 6minutes on the dot

hidden fox
#

what's the time spent on? i think some slowdown from dagger call is currently expected, we've got some optimizations we're doing

#

🎉

wintry isle
#

maybe i was impatient, on the first run it took way longer, on the second run it was 6minutes 8 seconds completly

#

definetly fixed now 🙂

#

will this change also be refleceted when using dagger run?

hidden fox
#

how do you mean? I think the fetching improvements should apply to dagger run as well.

rancid bear
rapid hamlet
#

@rain river Should be fixed by now, will be live for the next release

rancid bear
#

can also confirmed it's fixed with dagger run @wintry isle

#

thx @rapid hamlet for the quick fix 🙏

hidden fox
#

Wonderful 🎉 it'll ship with the next release later this week then!