Read listAll results as rows, not as a response
listAll goes through fetchAllPages, which pages past the server's 100-row cap and returns the rows themselves. Three asset forms read .data.data off that array. An array has no .data, so the second access threw and the surrounding Promise.all rejected, taking the whole load into the catch. On the PC edit page the throw landed before the record fetch, so no request was made for the computer at all. The form rendered with its reference data and no record, and the banner said only "Failed to load data" - which reads like a backend or schema fault and was twice diagnosed as one. The server logs settled it: every reference endpoint answered 200 and the record was never requested. MachineForm already carried a comment describing this exact trap, added when pcsRes hit it. Two adjacent lines had the same defect and were missed, so the comment now sits above all of them. Report the failure honestly while here. apiError only reads err.response, so a client-side TypeError produced nothing but the fallback string no matter how many times the page was reloaded. Fall back to err.message when there is no response, which is what identified this.
This commit is contained in:
@@ -187,8 +187,11 @@ onMounted(async () => {
|
||||
])
|
||||
types.value = typesResponse.data.data || []
|
||||
statuses.value = statusResponse.data.data || []
|
||||
// listAll resolves to the ARRAY, not a response: fetchAllPages already
|
||||
// unwrapped every page. Reading .data.data off it throws and takes the
|
||||
// whole parallel load into the catch.
|
||||
locations.value = locResponse || []
|
||||
businessunits.value = buResponse.data.data || []
|
||||
businessunits.value = buResponse || []
|
||||
|
||||
const assetType = (assetTypesResponse.data.data || []).find(a => a.assettype === 'measuring_tool')
|
||||
assettypeid.value = assetType ? assetType.assettypeid : null
|
||||
|
||||
Reference in New Issue
Block a user