Skip to content

Conversation

@vol4onok
Copy link
Contributor

@vol4onok vol4onok commented Jul 21, 2025

Release Table

Module Release Type Constraint Updates
EventBehavior minor

Module EventBehavior

Change log

Improvements

  • Introduced HydrateEventsRequest transfer.
  • Introduced HydrateEventsResponse transfer.
  • Introduced EventBehaviorFacadeInterface::hydrateEventDataTransfer() facade method to get event data with timestamp.

@snyk-spryker
Copy link
Collaborator

snyk-spryker commented Jul 21, 2025

🎉 Snyk checks have passed. No issues have been found so far.

code/snyk check is complete. No issues have been found. (View Details)

@vol4onok vol4onok requested review from demkos and stereomon July 21, 2025 13:59
@vol4onok
Copy link
Contributor Author

| Dependency violations in Spryker.EventBehavior |
+-------------------------+-----------------------------------------------------------+
| spryker/transfer | Dependency listed in composer require not found in source |
+-------------------------+-----------------------------------------------------------+
In suite. Spryker CV can be ignored

@stereomon
Copy link
Contributor

When CI is green, it's fine for me.

@vol4onok vol4onok changed the title FRW-10501: Extract event data with timestamps FRW-10501 Improve publish product logic based on timestamps. Aug 1, 2025
@vol4onok vol4onok requested a review from gechetspr August 4, 2025 06:32
{
$ids = [];
foreach ($eventTransfers as $eventTransfer) {
$ids[(int)$eventTransfer->getId()] = (int)$eventTransfer->getTimestamp();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so, if we go with the easiest flow that we can check. E.g. I've updating some big form on backoffice that have more than 1 entity in it. I put new data in it and it will trigger n+1 different events. There are not a 0 chance that those events will have the same id. With this approach we are going to loose some of the events.

The same goes for other similar methods

Copy link
Contributor Author

@vol4onok vol4onok Aug 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you see, we use the last one for a specific (unique) entity. It's part of the improvement

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. I still have my doubts, but please double check it on QA

return (new EventEntityTransfer())->setId($id);
return (new EventEntityTransfer())
->setId($id)
->setTimestamp(time());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we just set time from now, but we need to compare it with the time from the message. This is not according AC

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are those changes mentioned in the changelogs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it's enough here because we publish specific entities, we don't modify them.

Copy link
Contributor

@gechetspr gechetspr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code is ok. Looks like are skipping older events on publish phase as stated in AC

@spryker-release-bot spryker-release-bot merged commit a00c895 into master Aug 6, 2025
5 checks passed
@spryker-release-bot spryker-release-bot deleted the feature/frw-10501/master-p-and-s-improvement-based-on-timestamp branch August 6, 2025 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

6 participants