Issue in EDC 0.7.7 concerning AWS objectName/folderName when executing /v3/transferprocesses

[magnabschaller]

Bug Report

Specified AWS properties folderName & objectName in DataDestination properties for v3/transferprocesses

still original foldername from provider and original filename from provider is being taken (no overwrite possible)

Postman

S3 Bucket

Expected Behavior

expecting as in EDC 0.5.3 that foldername and object name are overwritten based on API properties

Observed Behavior

original filename & foldername have been used instead (original from data provider, not as specified as consumer)

Steps to Reproduce

Steps to reproduce the behavior:

1. Query Catalog of your partner
2. execute contract negotiation
3. initiate transfer for transferprocess ID with AWS properties as above in screenshot
4. See error inside AWS (wrong folder, wrong filename)

Context Information

Add any other context about the problem here.

• EDC 0.7.7

[github-actions]

Thanks for your contribution 🔥 We will take a look asap 🚀

[ndr-brt]

Seeing the version number I imagine you are referring to Tractus-X EDC, please open the issue in the correct repository:
https://github.com/eclipse-tractusx/tractusx-edc

[rafaelmag110]

The mentioned version is indeed wrong and doesn't belong to the EDC project but rather tractus-edc.

However, the content of the issue seems to be in the correct place and if there is an error in the way the foldername/objectname attributes are being used this is the place to solve them...

[gerbigf]

I was involved in the transfer in question. They are indeed using a Tractus-X EDC 0.7.7, but I've checked and there weren't any contributions to the s3 data plane extension that could have fixed the behaviour in one of the newer versions since 0.7.7. So I assume the issue is still valid.

[rafaelmag110]

tractusx-edc 0.7.7 uses eclipse-edc/technology-AWS v0.7.2. That's an important distinction that needs to be made since the upstream project is not aware of downstream versions.
The issue should be updated with that version.

[ndr-brt]

The issue is valid if it affects EDC 0.10.x version or the main branch.
If a fix is needed in T-X EDC 0.7.7, the issue needs to be opened downstream and tackled separately (because EDC version 0.7.2 that's used in T-X EDC 0.7.7 is not maintained anymore)