Skip to content

chore: Add troubleshooting entry for Fusion non-resync and env var workaround #770

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

chore: Add troubleshooting entry for Fusion non-resync and env var workaround #770

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
8083b67
chore: Add troubleshooting entry for Fusion non-resync and env var wo…
robnewman Aug 8, 2025
7728b87
Fix pluralization
robnewman Aug 8, 2025
ce8e8f4
Clarify limitations of when to apply
robnewman Aug 8, 2025
fe0608b
Merge branch 'master' into robnewman-studios-troubleshooting-fusion-e…
justinegeffen Aug 8, 2025
628ee79
Merge branch 'master' into robnewman-studios-troubleshooting-fusion-e…
justinegeffen Aug 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions platform-cloud/docs/troubleshooting_and_faqs/studios_troubleshooting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,18 @@ ERROR system error 2 (No such file or directory) [path:/sys/fs/cgroup/memory/mem

This is displayed because logging is set to `stderr` by default to ensure all logs are shown during the session, and can safely be ignored.

## Running session does not show new data in object storage

By default, Fusion does not resync objects from the remotely mounted data-link(s) after initial mounting. This means that when running a session with data mounted, if the underlying storage updates, the data is not re-synced to the studio session. This behavior can be changed when [adding a studio session](../studios/managing#add-a-studio) by defining the `FUSION_REFRESH_TIMEOUT` environment variable to N number of seconds (e.g. `30`). This will force Fusion to refresh the view of the mounted data-link(s) every N seconds.
Copy link
Contributor

@justinegeffen justinegeffen Aug 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
By default, Fusion does not resync objects from the remotely mounted data-link(s) after initial mounting. This means that when running a session with data mounted, if the underlying storage updates, the data is not re-synced to the studio session. This behavior can be changed when [adding a studio session](../studios/managing#add-a-studio) by defining the `FUSION_REFRESH_TIMEOUT` environment variable to N number of seconds (e.g. `30`). This will force Fusion to refresh the view of the mounted data-link(s) every N seconds.
By default, Fusion does not resync objects from remotely mounted data-link(s) after initial mounting.
If you have a running session with data mounted and the underlying storage is updated, the data will not be resynced to the Studio session.
You can change this behavior when you are [adding a Studio session](../studios/managing#add-a-studio) by defining the `FUSION_REFRESH_TIMEOUT` environment variable to a specified number of seconds (e.g., `30`). This will force Fusion to refresh the view of the mounted data-link(s) at the specified interval.


:::note
Setting the environment variable _inside_ an already running studio session by executing the command `export FUSION_REFRESH_TIMEOUT=30` won't change the behaviour of the outer Fusion session.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Setting the environment variable _inside_ an already running studio session by executing the command `export FUSION_REFRESH_TIMEOUT=30` won't change the behaviour of the outer Fusion session.
Setting the environment variable _inside_ an already running Studio session by executing the command `export FUSION_REFRESH_TIMEOUT=30` won't change the behavior of the outer Fusion session.

:::

:::warning
This is an experimental feature and may cause consistency issues in the Fusion namespace, resulting in data loss.
:::

## Container template image security scan false positives

### VS Code
Expand Down
12 changes: 12 additions & 0 deletions ...versioned_docs/version-25.2/troubleshooting_and_faqs/studios_troubleshooting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,18 @@ ERROR system error 2 (No such file or directory) [path:/sys/fs/cgroup/memory/mem

This is displayed because logging is set to `stderr` by default to ensure all logs are shown during the session, and can safely be ignored.

## Running session does not show new data in object storage

By default, Fusion does not resync objects from the remotely mounted data-link(s) after initial mounting. This means that when running a session with data mounted, if the underlying storage updates, the data is not re-synced to the studio session. This behavior can be changed when [adding a studio session](../studios/managing#add-a-studio) by defining the `FUSION_REFRESH_TIMEOUT` environment variable to N number of seconds (e.g. `30`). This will force Fusion to refresh the view of the mounted data-link(s) every N seconds.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
By default, Fusion does not resync objects from the remotely mounted data-link(s) after initial mounting. This means that when running a session with data mounted, if the underlying storage updates, the data is not re-synced to the studio session. This behavior can be changed when [adding a studio session](../studios/managing#add-a-studio) by defining the `FUSION_REFRESH_TIMEOUT` environment variable to N number of seconds (e.g. `30`). This will force Fusion to refresh the view of the mounted data-link(s) every N seconds.
By default, Fusion does not resync objects from remotely mounted data-link(s) after initial mounting.
If you have a running session with data mounted and the underlying storage is updated, the data will not be resynced to the Studio session.
You can change this behavior when you are [adding a Studio session](../studios/managing#add-a-studio) by defining the `FUSION_REFRESH_TIMEOUT` environment variable to a specified number of seconds (e.g., `30`). This will force Fusion to refresh the view of the mounted data-link(s) at the specified interval.


:::note
Setting the environment variable _inside_ an already running studio session by executing the command `export FUSION_REFRESH_TIMEOUT=30` won't change the behaviour of the outer Fusion session.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Setting the environment variable _inside_ an already running studio session by executing the command `export FUSION_REFRESH_TIMEOUT=30` won't change the behaviour of the outer Fusion session.
Setting the environment variable _inside_ an already running Studio session by executing the command `export FUSION_REFRESH_TIMEOUT=30` won't change the behavior of the outer Fusion session.

:::

:::warning
This is an experimental feature and may cause consistency issues in the Fusion namespace, resulting in data loss.
:::

## Container template image security scan false positives

### VS Code
Expand Down