Skip to content

Conversation

@w0wl0lxd
Copy link
Contributor

@w0wl0lxd w0wl0lxd commented Dec 1, 2025

Summary

  • Adds new auto_index_on_activate config option to ProjectConfig (defaults to false)
  • When enabled, automatically indexes all project source files after project activation
  • Pre-populates symbol caches for faster first queries on large projects

Changes

  • Added auto_index_on_activate: bool = False field to ProjectConfig dataclass
  • Implemented _auto_index_project() method in SerenaAgent that runs after LSP initialization
  • Updated project.template.yml with documentation for the new option
  • Added 3 unit tests for config parsing behavior

Test plan

  • Run uv run poe format - passes
  • Run uv run poe type-check - passes
  • Run uv run poe test - all 10 config tests pass
  • Manual test: Enable option in a project.yml and verify indexing runs on activation

Add a new project-level configuration option that automatically indexes
the project when it is activated. This pre-populates symbol caches for
faster first queries without requiring manual `serena project index`.

Changes:
- Add auto_index_on_activate field to ProjectConfig (default: false)
- Implement _auto_index_project() method in SerenaAgent
- Call auto-indexing after language server initialization
- Add documentation in project.template.yml
- Add unit tests for config parsing
@w0wl0lxd w0wl0lxd force-pushed the feature/auto-index-on-activate branch from 143867f to f5d42b6 Compare December 1, 2025 15:07
@opcode81
Copy link
Contributor

opcode81 commented Dec 9, 2025

I am not really convinced this is a useful feature, because it is likely to waste more time than it saves. Did you really find it beneficial to enable this?

@w0wl0lxd
Copy link
Contributor Author

I am not really convinced this is a useful feature, because it is likely to waste more time than it saves. Did you really find it beneficial to enable this?

for large codebases and on startup for the day, yeah it's highly beneficial. normally im running serena project index at least 5-10 times a day when working on a large codebase, and due to the amount serena tends to freeze or need a restart (claude code) it saves a lot of effort of doing so

@MischaPanch
Copy link
Contributor

normally im running serena project index at least 5-10 times a day when working on a large codebase

I don't understand this, the indexing should be performed just once, the index is automatically and incrementally updated after. Why do you have to do this? Are you starting 5-10 new projects or switching computers every day?

@opcode81
Copy link
Contributor

I see how it could help for cases where you switch between git branches where a large number of files are different, for example.

if self._project_activation_callback is not None:
self._project_activation_callback()

def _auto_index_project(self, project: Project) -> None:
Copy link
Contributor

@MischaPanch MischaPanch Dec 12, 2025

Choose a reason for hiding this comment

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

this duplicates the indexing logic that we already have in other places. If we decide to implement this feature, the duplication should be resolved.

We also have to make sure that it doesn't block the MCP server from connecting. It may also be very annoying to users (or to the LLM that calls our tools) that tools are unresponsive before the project is indexed. Maybe it makes sense to run this one thing in a separate process

@w0wl0lxd
Copy link
Contributor Author

apologies for the late reply! i've been on a ☃️ snowy vacation (happy holidays 😄)

normally im running serena project index at least 5-10 times a day when working on a large codebase

I don't understand this, the indexing should be performed just once, the index is automatically and incrementally updated after. Why do you have to do this? Are you starting 5-10 new projects or switching computers every day?

not sure if this is intended/unintentional behavior, but with Rust/Rust-Analyzer, the symbols don't incrementally update properly at all. i noticed this ~3-4 months ago maybe, but the "Enable Check on Save" RA config setting, as well as some other odd RA behavior will cause Serena's symbol cache to either expire or need to be rebuilt VERY often. Serena will freeze at times due to this when running the get_symbols_overview tool, and will often pull from an outdated symbol cache.

this duplicates the indexing logic that we already have in other places. If we decide to implement this feature, the duplication should be resolved.

We also have to make sure that it doesn't block the MCP server from connecting. It may also be very annoying to users (or to the LLM that calls our tools) that tools are unresponsive before the project is indexed. Maybe it makes sense to run this one thing in a separate process

i'm happy to rework this PR/create a new one to unblock this in my free time this week. in regards to your comment, in local testing i did notice that (at least in Rust codebases, which is a critical detail of this probably, i really only work with Rust, but i'll test this behavior with other languages) Serena will take a long time to initialize with this integrated in Rust codebases, especially large workspaces with many crates/artifacts, as Serena has to wait on Activation (where i placed the config setting call/command) for RA to check/build/compile artifacts before it's unblocked, mirroring the behavior that happens if you were to open two IDE's/terminal instances, and run cargo check --workspace or cargo build in one, and attempt to run a similar command in the other terminal (with RA LSP active/being used) freeze/become unresponsive VERY often with large amounts of file changes or build dependencies added, even with the "Enable Check on Save" config option disabled.

i'll look into the behavior in other languages, but as far as Rust goes, it seems like there's not an easy way to have it be non-blocking and would definitely cause the annoyances you've mentioned here.

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.

3 participants