CI fail in PR#538: recordDevDeployedContracts() fails with KeyError: 'development'

[trentmc]

Background

This was found in PR#538

Putting into its own github issue, because there's a chance it's not due to the PR itself. (However there is a chance it is, since this PR adds an import of ocean.py, thereby using Ocean contracts in a different way.)

There may be an issue with barge (not) waiting.

Traceback summary: (details below)

INTERNALERROR>   File "/home/runner/work/df-py/df-py/util/test/conftest.py", line 25, in pytest_sessionstart
INTERNALERROR>     recordDevDeployedContracts()
...
INTERNALERROR>   File "/home/runner/work/df-py/df-py/util/oceanutil.py", line 44, in recordDeployedContracts
INTERNALERROR>     a = json.load(json_file)[network]  # dict of contract_name: address
INTERNALERROR> KeyError: 'development'

Full log

Here.

Traceback

...
Generating build data...
 - GNSPS/solidity-bytes-utils@0.8.0/BytesLib
 - OpenZeppelin/openzeppelin-contracts@4.2.0/Ownable
...
 - SmartWalletChecker
 - veAllocate

Attached to local RPC client listening at '127.0.0.1:8545'...
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/_pytest/main.py", line 267, in wrap_session
INTERNALERROR>     config.hook.pytest_sessionstart(session=session)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/pluggy/_hooks.py", line 265, in __call__
INTERNALERROR>     return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/pluggy/_manager.py", line 80, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/pluggy/_callers.py", line 60, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/pluggy/_result.py", line 60, in get_result
INTERNALERROR>     raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/pluggy/_callers.py", line 39, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/home/runner/work/df-py/df-py/util/test/conftest.py", line 25, in pytest_sessionstart
INTERNALERROR>     recordDevDeployedContracts()
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/enforce_typing/decorator.py", line 29, in wrapper
INTERNALERROR>     return func(*args, **kwargs)
INTERNALERROR>   File "/home/runner/work/df-py/df-py/util/oceanutil.py", line 30, in recordDevDeployedContracts
INTERNALERROR>     recordDeployedContracts(address_file)
INTERNALERROR>   File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/enforce_typing/decorator.py", line 29, in wrapper
INTERNALERROR>     return func(*args, **kwargs)
INTERNALERROR>   File "/home/runner/work/df-py/df-py/util/oceanutil.py", line 44, in recordDeployedContracts
INTERNALERROR>     a = json.load(json_file)[network]  # dict of contract_name: address
INTERNALERROR> KeyError: 'development'
/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/site-packages/brownie/network/main.py:44: BrownieEnvironmentWarning: Development network has a block height of 18
  warnings.warn(
Error: Process completed with exit code 3.

[calina-c]

Seems like a duplicate of #421. @trentmc is it all right if I use just one of these tickets and close the other one?

[trentmc]

Seems like a duplicate of #421. @trentmc is it all right if I use just one of these tickets and close the other one?

OK, I marked the other one as duplicate and closed it.

[trentmc]

Related: I'm having an issue with the same symptoms locally too. It's blocking me. I just reported it in #562. I think it's a barge issue.

[trentmc]

As Calina commented in slack: the symptom (KeyError) will occur if there are any failures on the barge side. For fixing #562 it came down to clearing the right cache.

As it's super hard to debug this with just the higher-level symptom, I'll close this issue. What we can do over time is make barge itself easier to debug.