Skip to main content

Documentation Index

Fetch the complete documentation index at: https://doc.lucidworks.com/llms.txt

Use this file to discover all available pages before exploring further.

Common issues and solutions for Platform signals integration in Fusion.

​
Signal retrieval not working

Symptom: Fusion’s signal processing component is not running or crashes repeatedly. Diagnosis: 
kubectl get pods -l app.kubernetes.io/component=signals-operator
kubectl logs -l app.kubernetes.io/component=signals-operator --tail=50
Common Causes:
  1. Missing or incorrect LWAI credentials
    • LWAI gateway credentials are not configured in Helm values.
    • Client ID and Secret don’t match the Platform integration.
    • The baseUrl doesn’t point to the correct Platform application.
  2. ConfigMap syntax errors
    • The cloud-signals-config ConfigMap syntax is not valid YAML.
    • The signalsOperator section has incorrect indentation.
Solution: Review and correct the credentials, then restart the pod: 
kubectl delete pod -l app.kubernetes.io/component=signals-operator

​
Authentication failures

Symptom: Signal retrieval logs show authentication errors. Example Log: 
ERROR c.l.c.s.c.f.s.SignalsServiceClientImpl - Response code:400, message:{"error":"validation","message":"Requested account profile is not known."}
Diagnosis: Check the signal retrieval logs for authentication errors: 
kubectl logs -l app.kubernetes.io/component=signals-operator | grep -i "error\|failed"
Common Causes:
  1. Integration name mismatch
    • The integration name in Helm values doesn’t match the Platform integration name.
  2. Expired or invalid credentials
    • The Client ID or Secret are incorrect.
    • The integration was deleted or modified in Platform.
  3. Incorrect auth endpoint
    • The authEndpoint URL is wrong or inaccessible.
Solution:
  1. Verify integration name matches exactly (case-sensitive).
  2. Regenerate Client ID and Secret in Platform.
  3. Update Helm values with correct credentials.
  4. Redeploy or restart affected pods.

​
No signals in collection

Symptom: The COLLECTION_NAME_signals_aggr collection is empty or not populated. Diagnosis:
  1. Check whether the collection exists in Fusion Admin UI:
    • Navigate to Collections.
    • Search for COLLECTION_NAME_signals_aggr.
  2. Check signal retrieval logs: 
    kubectl logs -l app.kubernetes.io/component=signals-operator --tail=100
Common Causes:
  1. No signals in Platform Signals Store
    • Beacon is not configured or not tracking events.
    • The Platform aggregation job hasn’t run yet.
  2. Signal retrieval not processing
    • The job status shows FAILED.
    • No export job is found in logs.
  3. Collection name mismatch
    • The collection name in the ConfigMap doesn’t match the Fusion app name.
Solution:
  1. Verify signal collection is working:
  2. Review signal retrieval logs for processing status: 
    INFO  c.l.c.s.c.fetcher.SignalsOperator - Found jobId in progress: <job_id>
INFO  c.l.c.s.c.fetcher.SignalsOperator - Job status: SUCCEEDED
  3. Verify collection name format:
    • The collection name should be COLLECTION_NAME_signals_aggr.
    • The name must exactly match the ConfigMap configuration.

​
Incorrect signal weights

Symptom: Documents are boosted, but weights don’t match expected values. Diagnosis: Query the signals collection to inspect weights, usually in the weight_d field. Common Causes:
  1. Formula configuration mismatch
    • Formula weights in the signal retrieval configuration don’t match the Platform formula.
    • The wrong formula name is specified in the Boost with Signals stage.
  2. Field mapping issues
    • The Rollup Weight Field in the query stage doesn’t match the signal document field.
Solution:
  1. Verify formula configuration matches Platform:
    • Check Platform formula definition.
    • Update signal retrieval configuration to match.
  2. Verify Boost with Signals stage configuration:
    • Aggregation Type must match formula name (e.g., formula1).
    • Rollup Weight Strategy must be weight_d.

​
Query boosting not working

Symptom: Queries execute successfully but results are not boosted based on signals. Diagnosis:
  1. Check whether the Boost with Signals stage is enabled in the query pipeline.
  2. Run a query with debug enabled: debug=true.
  3. Review boost parameters in the debug output.
Common Causes:
  1. Stage not in pipeline
    • The Boost with Signals stage is missing or disabled.
  2. Wrong aggregation type
    • The Aggregation Type in the stage doesn’t match the signals formula.
  3. Field name mismatch
    • The Rollup Field value doesn’t match the signal document field names.
  4. Empty signals collection
    • No matching signals exist for the query.
Solution:
  1. Add or enable the Boost with Signals stage in the query pipeline.
  2. Verify the stage configuration:
    • Aggregation Type: formula1
    • Rollup Field: doc_id
    • Rollup Weight Strategy: weight_d
  3. Test with a known query that has signals:
    • Query the signals collection to find a query with aggregated data.
    • Execute that query through the pipeline.
    • Verify boosting is applied in the debug output.

​
Slow query performance

Symptom: Queries with signal boosting are significantly slower than without. Diagnosis: Enable query timing and examine the Boost with Signals stage performance: 
debug=true&debugQuery=true
Common Causes:
  1. Large number of signals retrieved
    • The numSignals parameter is set too high.
  2. Inefficient signals collection query
    • Solr Query Parameters are missing or incorrect.
Solution:
  1. Tune Boost with Signals stage parameters:
    • Reduce numSignals to a reasonable value (50-100).
    • Reduce numRecommendations if appropriate.
  2. Optimize signals collection:
    • Make sure appropriate fields are indexed.
    • Consider adding filters to limit signal retrieval scope.

​
Log analysis

​
Successful run

Successful signal retrieval shows: 
INFO  c.l.c.s.c.fetcher.SignalsOperator - Starting control loop
INFO  c.l.c.s.c.fetcher.SignalsOperator - Found jobId in progress: <job_id>
INFO  c.l.c.s.c.f.s.SignalsServiceClientImpl - Checking export job status
INFO  c.l.c.s.c.fetcher.SignalsOperator - Job status: SUCCEEDED
INFO  c.l.c.s.c.fetcher.IndexingRunner - Found input file: gs://...
INFO  c.l.c.s.c.fetcher.IndexingRunner - Object node: {"query_s":"...","doc_id":"...","type":"...","weight_d":...}
INFO  c.l.c.s.c.fetcher.IndexingRunner - Converting to SolrDoc

​
Failed run

A failed run shows: 
ERROR c.l.c.s.c.f.s.SignalsServiceClientImpl - Response code:400, message:{...}
INFO  c.l.c.s.c.fetcher.SignalsOperator - Job status: FAILED

​
Getting help

If you continue to experience issues after following this guide, take these steps:
  1. Collect diagnostic information:
    • Signal retrieval logs (last 200 lines).
    • Helm values configuration (redact secrets).
    • Signal retrieval configuration.
    • Sample signals collection documents.
  2. Verify Platform integration:
    • Check Platform application status.
    • Verify integration credentials.
    • Review Platform signals aggregation jobs.
  3. Contact Lucidworks Support with the collected diagnostic information.