ExportXMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Component/s: None
    • Builder Changes Needed
    • Hide

      Summary of necessary driver changes

      •  

      Commits for syncing spec/prose tests
      (and/or refer to an existing language POC if needed)

      •  

      Context for other referenced/linked tickets

      •  
      Show
      Summary of necessary driver changes   Commits for syncing spec/prose tests (and/or refer to an existing language POC if needed)   Context for other referenced/linked tickets  

      Summary

      What is the problem or use case, what are we trying to achieve?

      numCandidates value will be made Optional, and when omitted, mongot will compute a system-derivec vlaue instead of error message. Filing proactively ahead of mongot design finalization

      Motivation

      Who is the affected end user?

      Who are the stakeholders?

      Users rewriting queries or writing net-new queries

      How does this affect the end user?

      Are they blocked? Are they annoyed? Are they confused?

      numCandidates}} is a required parameter today with no good default
      guidance (docs contradict themselves on the 10x/20x heuristic). In builder
      APIs this likely means the corresponding setter/constructor arg moves from
      required to optional.

      How likely is it that this problem or use case will occur?

      Main path? Edge case?

      Main path, today numCandidates is Required, making this Optional will affect all queries.

      If the problem does occur, what are the consequences and how severe are they?

      Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?

      We need compatibility through the driver interfaces to obviate the cognitive burden from this value today, and have the Optional, system derived value flow through to en d users.

      Is this issue urgent?

      Does this ticket have a required timeline? What is it?

      Search Query teams will begin this work in August and will plan to ship in ~3 months.

      Is this ticket required by a downstream team?

      Needed by e.g. Atlas, Shell, Compass?

      This capability should be reflected in all interfaces (Search Web Platform team will need to update in shell and compass)

      Is this ticket only for tests?

      Does this ticket have any functional impact, or is it just test improvements?

      Functional impact

      Acceptance Criteria

      What specific requirements must be met to consider the design phase complete?

      uery builders accept a $vectorSearch stage without numCandidates
      and do not error client-side.

      • No behavior change for callers who explicitly set numCandidates.
      • Confirm per-language whether any driver currently enforces
        numCandidates as client-side-required

            Assignee:
            Unassigned
            Reporter:
            Margaret Matern
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: