vscode: FileDecorationProvider intermittently fails

Does this issue occur when all extensions are disabled?: No - I have raised https://github.com/microsoft/vscode-python/issues/17432 with the offending extension but I believe that something in VS Code may also be broken.

  • VS Code Version: Code 1.60.1 (83bd43bc519d15e50c4272c6cf5c1479df196a4d, 2021-09-10T17:09:14.403Z)
  • OS Version: Darwin x64 20.6.0

I am currently developing a data science extension for iterative.ai which will integrate VS Code with the DVC cli (which is an open source Python project for versioning machine learning projects). Part of the extension is to do with large file management. In each repository we will have a list of Uris that are gitignored but tracked by DVC. We want to deliver as native an experience as possible to users so we decorate these Uris with colors that match up to the native git extension statuses (gitDecoration.addedResourceForeground, etc).

We register our FileDecorationProvider as close as possible to the instantiation of the extension however, recently the decorations have (intermittently) started getting stomped by the gitignore decoration.

If I disable the Python extension then the decorations appear as expected but we would really like to be able to reliably run the extension in parallel with other extensions, especially ms-python.python (as we want to integrate with as much of the existing data science toolkit as possible).

I have looked into the source code and it appears that all of the decoration providers have the same weight applied. I am wondering if something has changed recently and also how our extension can be effected by the Python one in this way.

How are conflicts between FileDecorations resolved? Is there anything that can be done on my end to mitigate this issue?

Ideally we need a way to reliably register a FileDecorationProvider that will not be overwritten by the native git extension under unknown circumstances. The reason that I am raising a bug is because this worked up to a few days ago, I cannot find anything in the docs and I thought it was a solved problem. If this is a feature request then please let me know.

Steps to Reproduce:

  1. Run extension in parallel with ms-python.python.
  2. FileDecorations will intermittently be overwritten (static per session, i.e they work or they don’t).

Note: When starting up our extension having the ms-python.python installed vs not installed takes instantiation time from < 20ms to ~300ms.

Thanks for taking the time to read this 👍🏻 . Please let me know if need any further details.

Extra details captured by extension bisect:

System Info
Item Value
CPUs Intel® Core™ i9-9880H CPU @ 2.30GHz (16 x 2300)
GPU Status 2d_canvas: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled
Load (avg) 5, 3, 3
Memory (System) 16.00GB (0.20GB free)
Process Argv –crash-reporter-id 343c20dd-d8ac-482e-bcc6-2244d6ab7bb5
Screen Reader no
VM 0%
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
vshan820:30294714
vstes263cf:30335440
pythonvsuse255:30340121
vscod805cf:30301675
vscextlangct:30333562
binariesv615:30325510
vsccppwt:30364497
bridge0708:30335490
pygetstartedt2:30360495
bridge0723:30353136
javagetstartedt:30364666
pydsgst2:30361792
vssid140cf:30363604
vssur157:30365996

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 18 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Pushed a fix. This time a test too 🙈

Of course it will

Oh, no… Sorry for that. Clear a regression, I guess my brain is wired to use push over unshift

Would being able to apply a weight to the decorations be a better long term solution? (we could then provide config options to users down the track so that they can reorder themselves).

We avoid weights because eventually all weights will be at the highest possible value and the problem repeats (just with extra complexity…) It happens that N extension contributed features conflict and than extension-configuration is key, like uninstall one extension or make extensions configurable so that they allow to resolve conflicts (like a setting to not decorate ignore files etc)

The lifo-approach for providers is something we are doing elsewehere (e.g. language providers) and that’s the best we can do for now. I am closing this without further actions

I have pushed a change so that later decoration provider are asked for decorations first. Please try this out with tomorrows insiders

is that the color decorations from each FileDecorationProvider are displayed on the basis of when each was registered. It is a first come, first served basis.

Correct - we store decoration provider into a linked list and ask them in order