DELETEing an already deleted asset responds with old asset value; expected MTConnectError about cppagent HOT 14 CLOSED

I think we need better docs in the model. The removed behavior is given here:

Asset Request

What your observing is the correct behavior. The asset is marked as removed and sent to the bottom of the asset buffer to be removed when the assets overflow. The idea is that an asset removed may still be useful but is not guaranteed to be kept alive. The use case is when a tool is removed from a tool magazine, its data may still be of use to an application, but it is not alive in the magazine. If you want assets that are also removed, you can add removed=true as a query parameter, and it will show the removed assets.

This was a requirement when we first developed the tooling model.

Best

• W

from cppagent.

We should have this discussion In the agent or shop floor info mgmt working groups. Can you attend?

from cppagent.

The default request for the current list of assets defaults to not including removed assets. An asset requested by id will return the asset since you are identifying the asset by uuid.

from cppagent.

another test:

I POST an asset with the following:

curl -d @LoadCnc.xml 'http://192.168.0.105:5000/asset/LoadCnc?device=machine_1&type=AdapterConfig'

The agent responds with a valid MTConnectAssets document reflecting the asset POSTed; as expected.

I then DELETE it with the following:

curl -X DELETE 'http://192.168.0.105:5000/asset/LoadCnc?device=machine_1&type=AdapterConfig'

I confirm it is removed with the AssetRemoved dataitem.

I then try GETting the asset:

curl 'http://192.168.0.105:5000/asset/LoadCnc?device=machine_1&type=TaskArchetype'

The agent responds with a valid MTConnectAssets document reflecting the asset originally POSTed; but I was expecting an MTConnectError response.

from cppagent.

The assets are marked as removed, not actually deleted. The asset is still there, so the operation has no effect.

We should discuss this behavior in the Agent WG.

from cppagent.

oh, ok. i could see how that is useful for tooling. would Tasks be handled differently?

from cppagent.

curl 'http://192.168.0.105:5000/asset/LoadCnc?device=machine_1&type=TaskArchetype&removed=false'

still responds with the previously deleted asset...what am i doing wrong?

according to sysML:

value for  Agent::removed MUST be true or false and interpreted as follows:

    true: MTConnectAssets Response Documents for assets marked as removed MUST be included in the response document.

    false: MTConnectAssets Response Documents for assets marked as removed MUST NOT be included in the response document.

If  Agent::removed is not given, the default value MUST be false.

... I am interpreting that to mean removed defaults to false...and therefore "assets marked as removed MUST NOT be included in the response"

from cppagent.

I'll check this out. They shouldn't include removed assets.

from cppagent.

Looks like the /assets/{assetIds}? and /asset/{assetIds}? routes dont have removed={bool:false} as get request parameters.
RestService::createAssetRoutings() ~line 566

I added a Pull request which adds the removed parameter to those routes

from cppagent.

x-posted from pr (here: #449 ); we can pickup the discussion here:

oh, i see removed="true" in the asset xml element. the issue is removed=true gets included in the response to both the first DELETE REST call, and any subsequent DELETE calls with the same asset id. (until the buffer cycles; obviously)

so it doesnt seem like there is a way to distinguish if the asset was deleted now because of my most recent DELETE or some previous action some time ago

I think honoring the ?removed=false param on /asset/{addetId}?removed=false and /assets/{addetId}?removed=false would mitigate this, but i do see that might be a breaking change for many client apps that would now have to specify ?removed=true in their REST call.

We're open to other ideas?

from cppagent.

after sleeping on it; it occured to me that we could compare the MTConnectAssets' Header creationTime and the assets' removed=true state along with timestamp to determine if the assset was deleted now or previously

i feel a little stupid for not thinking of that... 🤦

IMO removed assets shouldnt be included by default. I get keeping them accessible, but it seems most logical to me that a client app should explicitly request the response to include removed assets

from cppagent.

This was done for a reason. An asset that is removed may have updated data and based on the AssetRemoved event we can get the latest update even after the asset is removed. This feature is necessary for cutting tools and other asset types.

Does this make sense.

from cppagent.

it does make sense. its all a trade off between computing logic in the adapters vs the agent.

IMO, "removed" in the mtconnect sense is a different function than the REST delete.

I think "removing" an asset should involve the owner of the asset updating it with removed=true parameter. Similar as they would over SHDR w/ @REMOVE_ASSET@. Just execute another POST, adding removed=true to the asset. I think REST delete should just delete it, dead, gone.

assets that overflow the buffer are not recoverable anyways, right?

TLDR - remove != delete

All that being said; This isnt a hill im willing to die on. If this isnt canon then it isnt and thats ok. I realize this could imply a breaking change to existing client apps that would now have to include removed=true in their REST query.

from cppagent.

sounds good. ill close this issue then, and you can deny the PR

from cppagent.