Relay plugin causes sporadic errors

[dgreif]

@kwonoj we've been having a lot of success using @swc/plugin-relay so far, but it seems to sporadically fail in our CI environment. I've updated @swc/core, @swc/jest and @swc/plugin-relay but am still experiencing issues. Without @swc/plugin-relay, the tests pass every time. With @swc/plugin-relay, our Jest tests can fail in two different ways:

1. The Jest tests run to completion, but the final results are not logged and the process never exits, causing our CI build to timeout
2. Some tests fail with the following stacktrace. In these cases, the process often does not exit (See # 1)

 thread '<unnamed>' panicked at 'range end index 9725912 out of range for slice of length 4780000', library/core/src/slice/index.rs:73:5
stack backtrace:
   0:     0x7fdafe40c6ad - <unknown>
   1:     0x7fdafe43331c - <unknown>
   2:     0x7fdafe408241 - <unknown>
   3:     0x7fdafe40e045 - <unknown>
   4:     0x7fdafe40dcb9 - <unknown>
   5:     0x7fdafe40e5e2 - <unknown>
   6:     0x7fdafe40e4c7 - <unknown>
   7:     0x7fdafe40cb64 - <unknown>
   8:     0x7fdafe40e1f9 - <unknown>
   9:     0x7fdafcc97813 - <unknown>
  10:     0x7fdafe434f76 - <unknown>
  11:     0x7fdafe42b237 - <unknown>
  12:     0x7fdafe430366 - <unknown>
  13:     0x7fdafcc97926 - <unknown>
  14:     0x7fdafd5cbab1 - <unknown>
  15:     0x7fdafd5bc647 - <unknown>
  16:     0x7fdafd598619 - <unknown>
  17:     0x7fdafd51cd95 - <unknown>
  18:     0x7fdafd5196bd - <unknown>
  19:     0x7fdafd518da9 - <unknown>
  20:     0x7fdafd4dfd25 - <unknown>
  21:     0x7fdafd4c702f - <unknown>
  22:     0x7fdafd1ddb58 - <unknown>
  23:     0x7fdafd4ec444 - <unknown>
  24:     0x7fdafd4e44f6 - <unknown>
  25:     0x7fdafd4e7770 - <unknown>
  26:     0x7fdafcf56cb8 - <unknown>
  27:           0xaadf9d - _ZN6v8impl12_GLOBAL__N_123FunctionCallbackWrapper6InvokeERKN2v820FunctionCallbackInfoINS2_5ValueEEE
  28:           0xd4a18e - _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE
  29:           0xd4b5af - _ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE
  30:          0x15e7959 - Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit

    failed to handle: range end index 9725912 out of range for slice of length 4780000

    Stack backtrace:
       0: <unknown>
       1: <unknown>
       2: _ZN6v8impl12_GLOBAL__N_123FunctionCallbackWrapper6InvokeERKN2v820FunctionCallbackInfoINS2_5ValueEEE
       3: _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE
       4: _ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE
       5: Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit

      at Compiler.transformSync (node_modules/@swc/core/index.js:137:25)
      at transformSync (node_modules/@swc/core/index.js:217:21)
      at Object.process (node_modules/@swc/jest/index.js:71:45)
      at ScriptTransformer.transformSource (node_modules/@jest/transform/build/ScriptTransformer.js:619:31)
      at ScriptTransformer._transformAndBuildScript (node_modules/@jest/transform/build/ScriptTransformer.js:765:40)
      at ScriptTransformer.transform (node_modules/@jest/transform/build/ScriptTransformer.js:822:19)

Unfortunately I can't recreate this locally so I can't provide a reproduction repo for you to see it in. Hopefully something in the stack trace stands out 😄. One note, the end index 9725912 is exactly the same in all cases of this error, while the slice length 4780000 can vary.

[kwonoj]

This sounds like sharing the same root cause to #32 .

The problem is as already shared in the comment, it's tricky to dig into as there's no easy way to repro at all.

@nickskotny or @dgreif , by any chance is it possible to configure CI to run debug build of plugin + swc/core to capture better backtrace? I'm aware it is not an easy ask as it'll noticeably slows down runtime performance. I have a backlog swc-project/swc#4177 to improve this but haven't made progress yet.

[dgreif]

I can definitely set that up. I can just configure it in a branch and kick of N builds. If I do 10-20 builds, at least one of them usually fails. Just let me know what flags I need to pass 😄

[kwonoj]

It needs to use custom swc / plugin binary as it is compile time configured. I do not think we have automatic way to publish this, probably need one-off way like using git dependencies in npm instead. I'll try to check and get back.

Mind let me know which binary CI actually uses? @swc/core-linux-x64-gnu?

[dgreif]

Yep, @swc/core-linux-x64-gnu. I'm going to jump on the SWC discord as well in case you want to chat there for quicker round trip 😄

[kwonoj]

Copying comment from discord:

I tried creating a reproduction yesterday but was unsuccessful. I decided to try ubuntu-latest as the base image for this CI build and it's had 50+ runs with no errors. I probably won't have time to look into it further any time soon, but I feel confident that ruby:2.5-slim-stretch as the base image holds the answer to recreating/fixing the issue.

It looks like there are some unknown issues around linux images on the CI. We can't conclude this yet, but would like to wrap up current issue and encourage to try different base images.

[dgreif]

@kwonoj I was not able to get a conclusive reproduction environment set up, but I'm confident that we are not seeing similar issues when using ubuntu-latest as our base image. I'm good with closing out this issue, though I wish we had been able to get to the root cause and exact line of code that is throwing the errors in SWC. If you are comfortable closing without that, I am as well.

One other piece of info, I set up our Webpack build to use SWC running on the same old stretch image, and it does not fail in this way. I'm not sure if it's some combination of @swc/jest and these plugins that causes the issue to appear, but webpack + the swc relay plugin does not fail in this way. Not sure if that helps 😄

[kaelig]

Edit: message moved to its own issue: #177

[dgreif]

@kaelig I'm not certain the error you are experiencing is related. So far, we have only been experience errors like thread '<unnamed>' panicked at 'range end index 9725912 out of range for slice of length 4780000'. It's interesting that you can avoid your errors when using --runInBand, but I'm guessing that's just a coincidence. Might be worth opening a separate issue with the details you provided above.

[kaelig]

Good point, I opened this issue instead: #177