Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.0] Display the item that reached the limit (objectId is too big ... contact us) #160

Open
tristanbes opened this issue Dec 5, 2017 · 3 comments · May be fixed by #309
Open

[3.0] Display the item that reached the limit (objectId is too big ... contact us) #160

tristanbes opened this issue Dec 5, 2017 · 3 comments · May be fixed by #309

Comments

@tristanbes
Copy link
Contributor

It would be nice to display the row that reached the limit to give us insights on what is really too big.
Not a priority though.

1__app_seek-team___srv_app__ssh_

@tristanbes
Copy link
Contributor Author

Also, I think it could be nice to continue indexing the other rows and at the end, display the objectId that was in error, and why, using a table helper.

What do you think ?

@nunomaduro
Copy link
Contributor

@tristanbes I don't think we should continue indexing the other rows and at the end, at least at the moment - as I consider this to be a RuntimeException.

But yeah, I would be great to have access to the doctrine entity information where this happened.

@tristanbes
Copy link
Contributor Author

I continue to think that throwing an exception is not what we can exept.

I just did some maintenance operation on my website which consist in 3 operations:

  • detect if users put some link in their description
  • remove found links
  • send emails

I got 50,000 rows to process.

At some point, the command crashes because of 1 item too big for Algolia. (Note that i'm using the Listeners from Doctrine)

So in a developper point of view:

  • I don't know which items from my DB were processed
  • Emails were sent
  • I didn't use algolia in the code. Just calling persist and flush

I'm using DoctrineBatchUtils so I can't wrap the persist/flush in a try/catch condition to catch Algolia exception.

Now I need to find out why this row is too big, and then launch the command again, risking sending 2x the same email to users.

Hope you can reconsider with this example.

@chloelbn chloelbn linked a pull request Jul 18, 2019 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants