The GitHub Actions job "Build" on jackrabbit-oak.git/issue/OAK-12348 has failed. Run started by GitHub user bhabegger (triggered by reschke).
Head commit for run: 1893ff0e971272ce51ce761c06f597cdf6687665 / Benjamin Habegger <[email protected]> OAK-12348: Property and node type indexes support costPerEntry/costPerExecution overrides PropertyIndex/NodeTypeIndex (oak-core) computed cost purely from indexed entry counts, with a fixed overhead of 2, and no way to influence the estimate from the index definition -- unlike Lucene/Elastic indexes (oak-search), which already read costPerEntry/costPerExecution. In production this caused the nodeType/property index to win cost comparisons against a more selective, purpose-built index for the same query (three related incidents), because the built-in entry-count estimate can be significantly wrong at scale. PropertyIndexPlan and PropertyIndexLookup now each split into getCostLegacy() (the original hardcoded formula), getCostConfigurable() (cost = costPerExecution + costPerEntry * entryCount, both optionally set on the property index definition), and getCost() which dispatches between them based on FT_OAK-12348 (enabled by default: with no properties set, getCostConfigurable() reproduces getCostLegacy() exactly, so this is behavior-preserving for every existing index definition; the toggle is an escape hatch, not an opt-in gate). NodeTypeIndex needs no changes at all -- its cost is the sum of two PropertyIndexLookup.getCost() calls (jcr:primaryType, jcr:mixinTypes), so it picks up the override transitively. IndexUtils gains a small public getOptionalValue(NodeState, String, double) helper (mirroring oak-search's IndexDefinition.getOptionalValue, which oak-core cannot depend on directly) used by both getCostConfigurable methods instead of duplicating the same property read twice. Report URL: https://github.com/apache/jackrabbit-oak/actions/runs/31580667021 With regards, GitHub Actions via GitBox
