Skip to content

fix: scale GitHub metadata loading and WebDAV listings - #91

Open
Palgogo wants to merge 10 commits into
TheodoreKrypton:masterfrom
Palgogo:fix/github-metadata-tree-loader
Open

Palgogo wants to merge 10 commits into
TheodoreKrypton:masterfrom
Palgogo:fix/github-metadata-tree-loader

Conversation

@Palgogo

@Palgogo Palgogo commented Sep 3, 2026

Copy link
Copy Markdown

Summary

Fixes two production-scale TGFS failure modes that appear during large metadata recovery:

  • Rebuild GitHub-backed metadata through complete recursive Git Trees walks instead of one Contents API request per directory.
    • Resolves slash-containing branch names through the Branch API.
    • Falls back only when a recursive tree response is truncated, splitting at immediate children.
    • Fails closed when a subtree cannot be retrieved completely.
  • Stream WebDAV PROPFIND Depth: 1 directory listings so a wide collection can start responding before all children are consumed.

Safety / behaviour

  • Metadata loading uses plain in-memory directory/file construction; it does not write to GitHub while reading.
  • Unsupported / unrepresentable entries are logged and skipped without discarding the remainder of a complete tree.
  • Existing GitHub write paths remain unchanged.

Validation

  • TGFS_DATA_DIR=. TGFS_CONFIG_FILE=config-test.yaml .venv/bin/pytest tests/tgfs/core/repository/impl/metadata/test_github_repo.py::TestGitTreeLoader tests/test_asgidav/test_propfind_streaming.py -q
    • 23 passed
  • git diff --check upstream/master...HEAD clean

Scope

This PR intentionally does not change production deployment, Compose configuration, rclone configuration, or the separate local-first/SQLite metadata work.

TGFSDirectory.find_files/find_dirs scanned the full entry list on every
name lookup. A depth-1 WebDAV PROPFIND resolves every child individually
(Folder.member -> Resource -> Ops.stat_file -> DirectoryApi.get_fr ->
find_files([name])), so listing a directory with N children cost O(N^2)
entry visits and made wide directories unresponsive.

Add a lazily-built name -> positions index per TGFSDirectory, validated by
an O(1) freshness fingerprint (entry count + identity of the last entry)
so direct list mutations (e.g. the GitHub metadata loader) cannot read a
stale index. No public signature or serialization change.

Measured: N=2000 children 1356.5ms -> 10.7ms (~127x); N=8000 children
23739.4ms -> 24.6ms (~965x); scaling changes from quadratic to linear.
@VulcanoSoftware

Copy link
Copy Markdown

Hello

The owner of this project is inactive for the last months. we (the community) have moved on to a fork of this project, maintained by a community member. you can find it here:

https://github.com/Xyvran/tgfs

we are still looking for more contributors, so your help is very welcome there :)

the fork also has a lot of more features and stuff, so chances are things you are trying to fix here are already present in the fork.

Greetings

@VulcanoSoftware

Copy link
Copy Markdown

https://github.com/VulcanoSoftware/dcfs

i also forked xyvran's fork and tried to replace the telegram backend with a discord backend. not because i don't like the telegram backend. i actually like the telegram backend more than the discord backend. but just for redundancy. when my dcfs project is production ready, my goal is to merge it into xyvran's tgfs to add raid 1 like redundancy by combining telegram and discord.

I am also looking for contributors :)

@VulcanoSoftware

Copy link
Copy Markdown

@Palgogo
dude, this project is dead.
move to https://github.com/Xyvran/tgfs
just like the whole community

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants