# How `get_app_search_source` Defines Searchable Applications in Coco App

> Learn how `get_app_search_source` in Coco App refreshes connector registries and rebuilds its index to define searchable applications from OS paths. Discover its core functionality.

- Repository: [INFINI Labs/coco-app](https://github.com/infinilabs/coco-app)
- Tags: internals
- Published: 2026-03-04

---

**The `get_app_search_source` Tauri command refreshes connector and datasource registries, triggering the `ApplicationSearchSource` to rebuild its index from OS application paths and determine which apps are available for search.**

The `get_app_search_source` function in the infinilabs/coco-app repository serves as the gateway for determining which applications appear in the Coco search interface. This Tauri command orchestrates the refresh of underlying data sources, ensuring the search index stays synchronized with the actual applications installed on your system.

## Command Entry Point in [`lib.rs`](https://github.com/infinilabs/coco-app/blob/main/lib.rs)

The `get_app_search_source` command is defined in [`src-tauri/src/lib.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/lib.rs) as an async Tauri command that accepts the `AppHandle` and returns a `Result`:

```rust
#[tauri::command]
async fn get_app_search_source(app_handle: AppHandle) -> Result<(), String> {
    let _ = server::connector::refresh_all_connectors(&app_handle).await;
    let _ = server::datasource::refresh_all_datasources(&app_handle).await;
    Ok(())
}

```

This implementation delegates the actual work to two server modules: `connector` and `datasource`.

## Refreshing Connectors and Datasources

The `get_app_search_source` command triggers two distinct refresh operations that rebuild the search infrastructure.

### Connector Registry Refresh

In [`src-tauri/src/server/connector.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/server/connector.rs), the `refresh_all_connectors` function iterates over every registered connector, including the application connector, and updates their internal state:

```rust
// Located in src-tauri/src/server/connector.rs
pub async fn refresh_all_connectors(app_handle: &AppHandle) {
    // Iterates connectors and triggers state updates
}

```

### Datasource Registry Refresh

Similarly, [`src-tauri/src/server/datasource.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/server/datasource.rs) contains `refresh_all_datasources`, which handles datasource updates. The application datasource is implemented by the `ApplicationSearchSource` trait object located in the built-in extension:

```rust
// Located in src-tauri/src/server/datasource.rs
pub async fn refresh_all_datasources(app_handle: &AppHandle) {
    // Refreshes all datasources including ApplicationSearchSource
}

```

## Application Search Source Architecture

The `ApplicationSearchSource` is registered during app startup in [`src-tauri/src/extension/built_in/mod.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/extension/built_in/mod.rs). The built-in extensions initialize the `SearchSourceRegistry` with the application source:

```rust
SearchSourceRegistry::default()
    .register_source(application::ApplicationSearchSource)

```

This registration makes the application source available to the datasource refresh mechanism triggered by `get_app_search_source`.

## How Searchable Applications Are Defined

The actual logic for determining which applications appear in search results depends on the platform-specific implementation of `ApplicationSearchSource`.

### Feature-Enabled Implementation

When the application search feature is enabled, [`src-tauri/src/extension/built_in/application/with_feature.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/extension/built_in/application/with_feature.rs) handles the indexing. This implementation:

1. Scans default OS application search paths plus user-added paths via `get_default_search_paths()`
2. Discovers installed applications using `list_app_in(search_path: Vec<String>)`
3. Builds a **PizzaEngine** index storing each discovered app as a document
4. Returns a `QuerySource` with `id` set to `"Applications"` via the `get_type()` method

```rust
pub fn get_default_search_paths() -> Vec<String> { 
    // Returns OS-specific application directories 
}

fn list_app_in(search_path: Vec<String>) -> Result<Vec<App>, String> { 
    // Discovers applications in specified paths 
}

impl SearchSource for ApplicationSearchSource {
    fn get_type(&self) -> QuerySource { 
        // Returns QuerySource { id: "Applications", ... } 
    }
    
    async fn search(&self, query: String) -> Result<QueryResponse, SearchError> { 
        // Queries the PizzaEngine index 
    }
}

```

### Feature-Disabled Fallback

On platforms where the application search feature is disabled, [`src-tauri/src/extension/built_in/application/without_feature.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/extension/built_in/application/without_feature.rs) provides a stub implementation that returns an empty result set, meaning no applications are searchable.

## Triggering the Refresh from the Frontend

The frontend triggers `get_app_search_source` via the Tauri command system. In [`src/components/SearchChat/index.tsx`](https://github.com/infinilabs/coco-app/blob/main/src/components/SearchChat/index.tsx), the React component invokes the command through a platform adapter:

```typescript
import { platformAdapter } from '@/utils/platformAdapter';

// In a component's initialization effect
useEffect(() => {
  if (isTauri) {
    // Triggers the Rust side to rebuild the application index
    platformAdapter.commands('get_app_search_source');
  }
}, []);

```

This call initiates the refresh cycle, causing the `ApplicationSearchSource` to rebuild its index from the current state of the filesystem.

## Summary

- **`get_app_search_source`** is a Tauri command in [`src-tauri/src/lib.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/lib.rs) that orchestrates the refresh of search data.
- The command delegates to **`refresh_all_connectors`** and **`refresh_all_datasources`** to update the underlying registries.
- The **ApplicationSearchSource** trait object, registered in [`src-tauri/src/extension/built_in/mod.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/extension/built_in/mod.rs), handles the actual application discovery.
- On supported platforms, **[`with_feature.rs`](https://github.com/infinilabs/coco-app/blob/main/with_feature.rs)** scans OS application paths, indexes discovered apps using **PizzaEngine**, and exposes them under the `"Applications"` query source ID.
- The frontend triggers this process via **`platformAdapter.commands('get_app_search_source')`** in the React layer.

## Frequently Asked Questions

### What happens if the application search feature is disabled?

When the feature is disabled, the codebase uses the fallback implementation in [`src-tauri/src/extension/built_in/application/without_feature.rs`](https://github.com/infinilabs/coco-app/blob/main/src-tauri/src/extension/built_in/application/without_feature.rs). This stub returns an empty result set for all queries, meaning no applications appear in search results regardless of what is installed on the system.

### How does `get_app_search_source` differ from directly querying installed applications?

The `get_app_search_source` command does not directly return application data to the frontend. Instead, it triggers an asynchronous refresh process that rebuilds the internal **PizzaEngine** index. The frontend must subsequently query the `ApplicationSearchSource` through the standard search interface to retrieve the actual application list.

### Can users customize which directories are scanned for applications?

Yes. While the implementation uses `get_default_search_paths()` to discover OS-specific application directories, the system supports user-added paths. The `list_app_in` function accepts a vector of search paths, allowing the extension to index applications from custom locations beyond the default OS directories.

### Where is the application index stored after `get_app_search_source` completes?

The index is maintained in memory by the **PizzaEngine** instance within the `ApplicationSearchSource` struct. The source implements the `SearchSource` trait, storing indexed application documents as a `QuerySource` with the identifier `"Applications"`. This volatile index is rebuilt each time the refresh command is invoked, ensuring search results reflect the current filesystem state.