Frontier kind: Joint frontier
unlabeled · c_cce06346348c
1 test · 2275 LOC · 92 files · introduces 1 test · 58 LOC · 1 file
The orange circle is the focus. Violet and green circles are every ancestor and descendant, broader and narrower, at any distance; blue squares and pink diamonds are the introduced files and exact introduced tests of every visible concept, not only the focus's. Arrows point from broader to narrower concepts and bridge only concepts omitted from this view. Undirected links show source or test introduction. Concept and file size follows LOC; exact test nodes use test-count units.
Introduced files, introduced tests, and structurally relevant concept specialization
In the embedded map, ordinary wheel input scrolls the page; use the visible controls to zoom and drag to pan. Open the full-screen map for canvas navigation: wheel pans, Ctrl/Command plus wheel zooms, and arrow keys pan when this region is focused. On touch screens, open the full-screen map to pan or pinch. If JavaScript or WebGL is unavailable, use the native relationship evidence on this page.
Graph controls are ready.
Interactive rendering requires JavaScript and WebGL. Use the native relationship evidence on this page while the interactive map is unavailable.
Every exact file and test below is linked only from the concept that introduces it.
go.temporal.io/server/common/circuitbreaker/TestTSCBWithDynamicSettingsgo.temporal.io/server/common/dynamicconfig/TestDeepCopy_OtherReferenceTypes_Nilgo.temporal.io/server/service/matching/configs/TestQuotasSuite/TestAPIPrioritiesOrderedgo.temporal.io/server/service/matching/configs/TestQuotasSuite/TestAPIToPriorityMappingEvery collected test enters the hierarchy at exactly one concept.
1 test introduced at this concept.
Every collected source range enters the hierarchy at exactly one concept.
1 file ranked by introduced lines: 58 introduced LOC across 5 ranges. Expand a file to inspect source; the > gutter marks introduced lines.
if strings.TrimSpace(request.Query) == "" {
}
parsedQuery, err := v.queryParser.Parse(request.Query)
request *archiver.QueryVisibilityRequest,
saTypeMap searchattribute.NameTypeMap,
// remaining is the number of workflow executions left to return before we reach pageSize.
remaining := request.PageSize
nextPageToken := request.NextPageToken
var executions []*workflowpb.WorkflowExecutionInfo
// We need to loop because the number of workflow executions returned by each call to query may be fewer than
// pageSize. This is because we may have to skip some workflow executions after querying S3 (client-side filtering)
// because there are 2 entries in S3 for each workflow execution indexed by workflowTypeName (one for closeTimeout
// and one for startTimeout), and we only want to return one entry per workflow execution. See
// createIndexesToArchive for a list of all indexes.
for {
searchPrefix := constructVisibilitySearchPrefix(uri.Path(), request.NamespaceID)
// We suffix searchPrefix with workflowTypeName because the data in S3 is duplicated across combinations of 2
// different primary indices (workflowID and workflowTypeName) and 2 different secondary indices (closeTimeout
// and startTimeout). We only want to return one entry per workflow execution, but the full path to the S3 key
// is <primaryIndexKey>/<primaryIndexValue>/<secondaryIndexKey>/<secondaryIndexValue>/<runID>, and we don't have
// the primaryIndexValue when we make the call to query, so we can only specify the primaryIndexKey.
searchPrefix += "/" + primaryIndexKeyWorkflowTypeName
// The pageSize we supply here is actually the maximum number of keys to fetch from S3. For each execution,
// there should be 2 keys in S3 for this prefix, so you might think that we should multiply the pageSize by 2.
// However, if we do that, we may end up returning more than pageSize workflow executions to the end user of
// this API. This is because we aren't guaranteed that both keys for a given workflow execution will be returned
// in the same call. For example, if the user supplies a pageSize of 1, and we specify a maximum number of keys
// of 2 to S3, we may get back entries from S3 for 2 different workflow executions. You might think that we can
// just truncate this result to 1 workflow execution, but then the nextPageToken would be incorrect. So, we may
// need to make multiple calls to S3 to get the correct number of workflow executions, which will probably make
// this API call slower.
res, err := v.queryPrefix(ctx, uri, &queryVisibilityRequest{
namespaceID: request.NamespaceID,
pageSize: remaining,
nextPageToken: nextPageToken,
parsedQuery: &parsedQuery{},
}, saTypeMap, searchPrefix, func(key string) bool {
// We only want to return entries for the closeTimeout secondary index. Keys for this
// index are always of the form:
// .../closeTimeout/<timestamp>/<runID>
// Walk from the end instead of splitting the whole string to avoid unnecessary
// allocations and to keep the logic clear:
// - drop <runID>
// - drop <timestamp>
// - check the remaining last segment equals "closeTimeout".
dir := path.Dir(key) // drop runID
dir = path.Dir(dir) // drop <timestamp>
return path.Base(dir) == secondaryIndexKeyCloseTimeout
})
if err != nil {
return nil, err
}
executions = append(executions, res.Executions...)
remaining -= len(res.Executions)
if len(nextPageToken) == 0 || remaining <= 0 {
break
}
}
Executions: executions,
NextPageToken: nextPageToken,
}, nil
}
for _, item := range results.Contents {
if keyFilter != nil && !keyFilter(*item.Key) {
}