fix(core): always send PFCP responses; treat datapath delete ENOENT as success - #650

Hi @zhangerfei-dp,

Thanks for this PR. In general the idea is clear and implemented well.

I'd recommend to process ENOENT error inside mapOperations in order not to care this error in calling code.

The second point is that you have to apply fix for delete operations in HandlePfcpSessionModificationRequest.

If you agree to move ENOENT error inside mapOperations, take into account DeleteUrr. This method currently returns data for URR. It may be difficult to implement new behavior because of that. It would be better to extract ReadURR explicitly.

Thanks for the review, Alex! Addressed in the rewritten branch (force-updated, single commit):

1. ENOENT moved into mapOperations — all deletes in cmd/ebpf (DeletePdrUplink, DeletePdrDownlink, DeleteDownlinkPdrIp6, DeleteFar, DeleteQer, DeleteUrr) now absorb key-absent via a small isKeyAbsent() helper (ebpf.ErrKeyNotExist / ENOENT). The cmd/core helper from the first revision is gone.
2. HandlePfcpSessionModificationRequest covered — RemoveFAR/RemoveQER no longer fail on absent entries thanks to the mapOperations change, and RemoveURR now uses ReadUrr + DeleteUrr.
3. DeleteUrr split — new ReadUrr(internalId) (UrrInfo, error) returns the usage data explicitly; DeleteUrr(internalId) error is conventional. Callers (session deletion + modification handlers) read first, then delete; the test mock is updated accordingly.

Checked: go build ./..., go vet ./cmd/... clean (tests compile), touched files gofmt-clean. Behavior re-verified on our churn workload (all Session Deletion Requests answered; rx == tx). Happy to iterate further.

Now error handling is perfectly incapsulated in mapOperations. But you removed changes in Handle():

Handle() — always transmit the handler's response when non-nil. A send error is logged, and only propagated when the handler itself succeeded.

Looks like this changes were OK.

-- BR, Alex

Restored the Handle() change — sorry it got lost in the rewrite, thanks for spotting it. Per your note: Handle() now always transmits the handler's response when non-nil; a send error is logged and only propagated when the handler itself succeeded (the handler's error is still returned as before).

Re-verified on the updated branch: go generate ./cmd/... + go build ./... + go vet ./... clean, go test ./cmd/core/... passes, and the churn workload keeps answering all Session Deletion Requests (rx == tx).

Thanks for the careful reviews and the guidance through the iterations, @pirog-spb — much appreciated!

This one came out of a real PFCP-session-churn scenario in our test rig, so it's great to see the fix land here. If anything else helps before merge (rebase, extra test evidence, etc.), just let me know — happy to assist.