Hi all,
we are running DSpace 10.0 (Docker) for testing and have encountered a reproducible issue where the /api/core/metadatafields/search/byFieldName endpoint consistently returns totalElements: 0 for all queries, making it impossible to add new metadata fields via the Edit Item → Metadata tab in the admin UI. The same endpoint works correctly on a fresh, unmodified DSpace 10.0 instance on the same server. We have performed an extensive bisection (dropping and rebuilding the database step by step) and confirmed that none of our configuration changes caused the issue. The database structure and all indexes are intact. Has anyone else encountered this, or is there a known fix or internal cache/index that could explain this behavior? I have attached a detailed bug report with all diagnostic steps, API responses and bisection results. Thanks in advance, Matthias Letsch Kommunikations-, Informations- und Medienzentrum (KIM) Universität Hohenheim, Stuttgart, Germany -- All messages to this mailing list should adhere to the Code of Conduct: https://lyrasis.org/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/53804762-2e62-4fc1-b192-48844d815fedn%40googlegroups.com.
# Bug Report: /api/core/metadatafields/search/byFieldName returns empty results on custom instance while working correctly on vanilla DSpace 10.0 **To:** [email protected] **Subject:** [DSpace 10.0] byFieldName search endpoint returns totalElements: 0 — Edit Metadata tab unusable --- ## Summary On our custom DSpace 10.0 instance, the REST endpoint `/api/core/metadatafields/search/byFieldName` consistently returns `totalElements: 0` for all queries (both structured parameters and free-text `query=`), making it impossible to add new metadata fields via the Edit Item → Metadata tab. The endpoint works correctly on a fresh, unmodified DSpace 10.0 instance running on the same server. --- ## Environment - DSpace Backend version: 10.0 (Docker image `dspace/dspace:dspace-10.0`, commit `465195f7593cf812fe16efaa1685a9a58823243c`) - DSpace Angular version: 10.0 (commit `7f59f6cf99f0d1fb4b2abe46e9f24a5e1ee01a49`) - Database: PostgreSQL 15 (Docker) - Solr: `dspace/dspace-solr:dspace-10.0` (Docker) - OS: Debian 13 (host), Docker 29.6.0 --- ## Steps to Reproduce 1. Run a fresh DSpace 10.0 Docker stack (standard setup per `docker-compose-dist.yml` + `docker-compose-rest.yml`) 2. Initialize entities (`dspace initialize-entities`), load metadata registry additions via `dspace registry-loader`, import community/collection structure via `dspace structure-builder`, submit and approve one test item 3. Use the instance normally for several days (entering metadata values via the submission form and Edit Item tab, approving items) 4. Open the Edit Item → Metadata tab in the admin UI 5. Try to add a new metadata field to an item (click `+Add`, type a field name such as `dc.title` or `local.title.sub`) 6. Observe the following inconsistent behavior: - Sometimes no suggestions appear at all - Sometimes the correct field appears as a suggestion and can be selected, but saving still fails with "Please choose a valid metadata field" - In both cases, the REST endpoint `byFieldName` returns either wrong results (a completely unrelated field) or `totalElements: 0`, even though the field is correctly present in the registry --- ## Observed Behavior All `byFieldName` queries return `totalElements: 0`, regardless of parameters: ``` GET /server/api/core/metadatafields/search/byFieldName?schema=dc&element=title&qualifier= → { "page": { "totalElements": 0 } } GET /server/api/core/metadatafields/search/byFieldName?query=title → { "page": { "totalElements": 0 } } GET /server/api/core/metadatafields/search/byFieldName?query=dc.subject → { "page": { "totalElements": 0 } } ``` --- ## Expected Behavior ``` GET /server/api/core/metadatafields/search/byFieldName?schema=dc&element=title&qualifier= → { "page": { "totalElements": 2 } } (dc.title, dc.title.alternative) GET /server/api/core/metadatafields/search/byFieldName?query=title → { "page": { "totalElements": 2 } } ``` (This is the actual result on our vanilla DSpace 10.0 reference instance — see "Vanilla Reference Comparison" below.) --- ## What Works Correctly - `GET /server/api/core/metadatafields/search/bySchema?schema=dc` → returns all 93 dc.* fields correctly - The metadata registry itself is intact (verified via direct SQL): ```sql SELECT COUNT(*) FROM metadatafieldregistry; -- returns 442SELECT element, qualifier FROM metadatafieldregistryWHERE metadata_schema_id = 1 AND element = 'title'; -- returns correct rows ``` - The submission form works correctly (metadata fields can be selected and saved during submission) - Custom Angular components reading metadata via `item.firstMetadataValue()` / `item.allMetadataValues()` work correctly --- ## Timeline and Observations The issue was **not present immediately after initial setup**. After a complete database rebuild and step-by-step bisection (see below), `byFieldName` worked correctly. The instance was then used normally over several days: metadata values were entered via the submission form and the generic Edit Item → Metadata tab (modifying existing field values, not adding new fields). During this period, new metadata registry entries were added via `dspace registry-loader`, and the `byFieldName` endpoint was verified to work correctly immediately after each registry change. The issue reappeared at some later point during normal frontend operation, without any identifiable single trigger. The only operations performed between the last confirmed working state and the rediscovery of the bug were: - Writing metadata values to existing fields via the frontend (submission form and Edit Item tab) - Approving items via the workflow No new registry entries, no configuration changes, and no Docker restarts occurred in that period. This suggests the issue may be related to a **state that degrades during normal REST API write operations**, rather than being caused by initial setup or configuration. --- ## Bisection / Diagnosis We performed an extensive bisection to identify the cause: 1. Dropped and recreated the database from scratch (fresh Flyway migration) 2. Tested `byFieldName` immediately → **works correctly** (`totalElements: 2` for `dc.title`) 3. Reapplied each configuration step one by one, testing after each: - `dspace initialize-entities` (2 runs) → still works ✅ - `dspace registry-loader` (local schema, 30 fields) → still works ✅ - `dspace registry-loader` (6 additional fields) → still works ✅ - `dspace structure-builder` (280 collections, 18 communities) → still works ✅ - Setting entity type on collection → still works ✅ - Creating admin user and roles → still works ✅ - Adjusting handle sequence (`setval`) → still works ✅ - Submitting and approving one test item → still works ✅ **Conclusion:** None of our configuration steps caused the issue. --- ## Vanilla Reference Comparison We set up a second, completely unmodified DSpace 10.0 Docker stack on the same server. On this vanilla instance, `byFieldName` works correctly for all queries. This confirms the issue is instance-specific, not a general DSpace 10.0 bug. --- ## Database Integrity Check We verified there are no data integrity issues in the custom instance: ``` \d metadatafieldregistry → All indexes present (PRIMARY KEY, metadatafield_schema_idx, metadatafieldregistry_idx_element_qualifier) → Foreign keys intact SELECT * FROM metadatafieldregistry WHERE element IS NULL OR metadata_schema_id IS NULL; → 0 rows (no NULL values) ``` --- ## Questions 1. Is there a known issue or fix related to `byFieldName` returning empty results in specific instance states? 2. Is there an internal cache or index (beyond Solr Discovery) that the `byFieldName` endpoint relies on, which could become inconsistent and would need to be rebuilt? 3. Are there any DSpace tools or commands that would reset/rebuild the internal state used by the `MetadataField` search endpoint? --- _Reported by: Kommunikations-, Informations- und Medienzentrum (KIM), Universität Hohenheim, Stuttgart, Germany_ _Contact: [email protected]_
