@@ -139,13 +139,14 @@ def convert(k: str, v: Any) -> Any:
139139 return v
140140
141141 results : list [JSON ] = []
142- offset = int (query .get ("offset" , 0 ))
142+ offset = int (query .get ("offset" , "0" ))
143143 limit = query .get ("limit" )
144144
145145 if limit :
146146 next_offset = offset + int (limit )
147147 paginated_name_list = name_list [offset :next_offset ]
148148 if next_offset >= len (name_list ):
149+ query ["offset" ] = str (len (name_list ))
149150 next_url = ""
150151 else :
151152 query ["offset" ] = str (next_offset )
@@ -167,7 +168,7 @@ def convert(k: str, v: Any) -> Any:
167168 "dataset.uploaded" : datetime .datetime .isoformat (
168169 dataset .uploaded
169170 )
170- },
171+ }
171172 }
172173 )
173174 q1 = {k : convert (k , v ) for k , v in query .items ()}
@@ -273,6 +274,17 @@ def compare_results(
273274 def test_dataset_list (self , server_config , query_as , login , query , results ):
274275 """Test `datasets/list` filters
275276
277+ NOTE: Several of these queries use the "limit" and/or "offset" options
278+ to test how the result set is segmented during pagination. These are
279+ represented in the parametrization above interchangeably as integers or
280+ strings. This is because (1) the actual input to the Pbench Server API
281+ is always in string form as a URI query parameter but (2) the requests
282+ package understands this and stringifies integer parameters while (3)
283+ the Pbench Server API framework recognizes these are integer values and
284+ presents them to the API code as integers. Mixing integer and string
285+ representation here must have no impact on the operation of the API so
286+ it's worth testing.
287+
276288 Args:
277289 server_config: The PbenchServerConfig object
278290 query_as: A fixture to provide a helper that executes the API call
0 commit comments