repro, status: config file error: Unsupported URL type b''://

[schuhschuh]

UPDATE (@shcheklein )

See this fast way to reproduce and the summary of the issue: #6530 (comment)

Bug Report

Description

I just upgraded DVC to version 2.6.4 and all of a sudden get this error with the same dvc.yaml file which worked fine previously. Note that while running these commands, another DVC process was running.

Reproduce

$ dvc status dvc.yaml
ERROR: config file error: Unsupported URL type b''://
$ dvc repro dvc.yaml --dry
ERROR: configuration error - config file error: Unsupported URL type b''://

Expected

Environment information

Output of dvc doctor:

$ dvc doctor
DVC version: 2.6.4 (conda)
---------------------------------
Platform: Python 3.9.6 on Linux-3.10.0-1160.15.2.el7.x86_64-x86_64-with-glibc2.17
Supports:
	http (requests = 2.25.1),
	https (requests = 2.25.1),
	s3 (s3fs = 2021.8.0, boto3 = 1.17.106)
Cache types: hardlink, symlink
Cache directory: xfs on /dev/md124
Caches: local
Remotes: s3, s3
Workspace directory: xfs on /dev/md124
Repo: dvc (subdir), git

Also observe this issue with DVC 2.5.4 after downgrading again:

> dvc doctor
DVC version: 2.5.4 (conda)
---------------------------------
Platform: Python 3.9.6 on Linux-3.10.0-1160.15.2.el7.x86_64-x86_64-with-glibc2.17
Supports:
	http (requests = 2.25.1),
	https (requests = 2.25.1),
	s3 (s3fs = 2021.6.1, boto3 = 1.17.49)
Cache types: hardlink, symlink
Cache directory: xfs on /dev/md124
Caches: local
Remotes: s3, s3
Workspace directory: xfs on /dev/md124
Repo: dvc (subdir), git

Additional Information (if any):

[daavoo]

Hi @schuhschuh ! Could you share the output of dvc status -v and a minimal dvc.yaml example to reproduce the bug?

[schuhschuh]

Find below the full stack trace.

$ dvc status -v dvc.yaml
2021-09-03 04:10:18,170 DEBUG: Lockfile 'dvc.lock' needs to be updated.
2021-09-03 04:10:18,174 ERROR: config file error: Unsupported URL type b''://
------------------------------------------------------------
Traceback (most recent call last):
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/command/status.py", line 54, in run
    st = self.repo.status(
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/__init__.py", line 49, in wrapper
    return f(repo, *args, **kwargs)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/status.py", line 145, in status
    return _local_status(
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/status.py", line 38, in _local_status
    return _joint_status(pairs)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/status.py", line 16, in _joint_status
    for stage, filter_info in pairs:
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/status.py", line 32, in <genexpr>
    self.stage.collect_granular(
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/stage.py", line 405, in collect_granular
    stages, file, _ = _collect_specific_target(
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/stage.py", line 98, in _collect_specific_target
    stages = loader.load_all(file, name, accept_group=accept_group)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/stage.py", line 286, in load_all
    return [stages[key] for key in keys]
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/repo/stage.py", line 286, in <listcomp>
    return [stages[key] for key in keys]
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/stage/loader.py", line 134, in __getitem__
    stage = self.load_stage(
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/stage/loader.py", line 88, in load_stage
    fill_stage_dependencies(stage, **deps)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/stage/utils.py", line 111, in fill_stage_dependencies
    stage.deps += loads_from(stage, deps or [], erepo=erepo)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/dependency/__init__.py", line 44, in loads_from
    return [_get(stage, s, info.copy()) for s in s_list]
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/dependency/__init__.py", line 44, in <listcomp>
    return [_get(stage, s, info.copy()) for s in s_list]
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/dependency/__init__.py", line 30, in _get
    return Dependency(stage, p, info)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/output.py", line 289, in __init__
    fs_cls, fs_config, path_info = get_cloud_fs(self.repo, url=path)
  File "/hf/home/aschuh/tools/conda/envs/istn_dl4/lib/python3.9/site-packages/dvc/fs/__init__.py", line 97, in get_cloud_fs
    raise ConfigError(str(exc)) from None
dvc.config.ConfigError: config file error: Unsupported URL type b''://
------------------------------------------------------------
2021-09-03 04:10:18,182 DEBUG: Analytics is disabled.

Sharing a minimial dvc.yaml to reproduce may be a bit more difficult. One thing here is that the dvc.yaml file provided as argument includes a first stage which references in deps the output of a stage from a dvc.yaml file in a sibling folder of the DVC project. Not sure if this is related, though. Does the stack trace tell you something what part of the dvc.yaml would be relevant to the issue?

[schuhschuh]

It appears #6059 modified get_cloud_fs() few months ago. Could this relate to the issue I have?

[schuhschuh]

My .dvc/config is:

[core]
    remote = store
    analytics = false
[cache]
    dir = /local/directory/path
    shared = group
    type = reflink,symlink
    slow_link_warning = true
['remote "cache"']
    url = s3://BUCKET_NAME/FOLDER_KEY_1
['remote "store"']
    url = s3://BUCKET_NAME/FOLDER_KEY_2

[schuhschuh]

Something very odd just happened.

I run dvc status dvc.yaml:stage_name which displayed the output just fine without errors. Then I thought I'd try this with all other stages defined in the dvc.yaml file to see if I can isolate the stage causing the error. But then when I run the command again for the exact same stage (stage_name as before when it worked), I again also got the error for this stage. Between running these dvc status commands, I have made no changes to the project files.

[shcheklein]

Hmm, hard to tell what's going on here. Not clear where does the empty URL schema comes from ('' in the message), and why it is a byte string "b" prefix.

@schuhschuh could you please run dvc config --list --show-origin

Also, file .dvc/config (+ file on any other config files if you have them). It would be nice to share them if there are more config files around (local, global, system).

[schuhschuh]

Yes, I understand this may be tricky.

> dvc config --list --show-origin
.dvc/config	remote.cache.url=s3://BUCKET/KEY
.dvc/config	remote.store.url=s3://BUCKET/KEY
.dvc/config	core.remote=store
.dvc/config	core.analytics=false
.dvc/config	cache.dir=/dvccache
.dvc/config	cache.shared=group
.dvc/config	cache.type=['reflink', 'symlink']
.dvc/config	cache.slow_link_warning=true

> file ../../../.dvc/config
../../../.dvc/config: ASCII text

I am running dvc both directly on a host server and inside a Docker container. In both cases, I was able to use dvc repro and dvc status fine a few times now, but all of a sudden see this error again.

[schuhschuh]

Also, I observe this issue both with DVC 2.5.4 after downgrading again as well as DVC 2.6.4.

[schuhschuh]

I think I just found the cause of this issue. I added a print statement of stage and deps arguments passed to fill_stage_dependencies() and discovered that the deps list included a boolean False value. This was caused by the following in the dvc.yaml:

stages:
  stage_name:
    cmd: ...
    deps:
      - ${eval.model_path}

where eval.model_path is set in the params.yaml file. I set this to false in order to indicate that the model to be evaluated is a dummy model without trainable parameters (used as a reference for comparison). Removing this line from the dependencies resolved the issue.

It would probably make sense to check whether the arguments are valid file path strings to produce a more helpful error message.

[shcheklein]

Okay, thanks @schuhschuh - this is very helpful! I was able to reproduce this quickly with the following dvc.yaml and params.yaml:

stages:
  test:
    cmd: touch res.txt
    deps:
        - ${output_path}
    outs:
    - res.txt

output_path: false

I see a few problems that we should address/create tickets for as a result of this research and I'll let team (cc @dberenbaum @efiop @skshetry ) decide on what tickets to create:

1. The obvious one - we don't do the schema check after we apply the value as we do for the dvc.yaml. Should we do a separate dvc.lock schema check pass as we do for dvc.yaml? cc @skshetry
2. Error - cryptic and not useful. It took a lot of time and effort to figure out what's going on because of this.

The way we handle this:

except Invalid as exc:
        raise ConfigError(str(exc)) from None

and

if parsed.scheme not in schemas:
            raise Invalid(f"Unsupported URL type {parsed.scheme}://")

doesn't give a chance in all these types of errors to understand the context.

(also, stack trace looks strange - dependency initializes output and runs get_cloud_fs when it's not output and it's not cloud, and internally is using remote config while it's not even about remote - it makes it even more confusing - sharing my experience looking into the issue)