Skip to main content
added 576 characters in body
Source Link
Nuno Linhares
  • 29.1k
  • 3
  • 42
  • 91

Try to explain this to the Business User: It shows success because it processed correctly every item that this publishing transaction was resolved to.

It is unfortunately not as easy to change this behavior as one would think (without performance impacts, which we all know is not what the Publishing Queue needs right now).

  • You send ItemX to the queue.
  • Publisher process picks it up
  • Resolver determines there's nothing to publish because of any reason and creates a List<ResolvedItem> with 0 items
  • Renderer loops through all items in the list, and there's no errors.
  • Transaction ends with # of errors = 0
  • Success

Nevertheless, this is something that we will try to address soon. It would also be incorrect to show it as a failure, because it did not fail, so probably a warning status with "There were no items to publish" message would be the better way to handle it.

If you're curious, this is what the Resolver has to say about it:

18:58:39.0317 <4204> Using resolver [Tridion.ContentManager.Publishing.Resolving.StructureGroupResolver]
18:58:39.3256 <4204> Resolving the structure groups [tcm:5-350-4] took 00:00:00.2853292
18:58:39.3285 <4204> StructureGroup tcm:5-350-4 resolved to 0 items. Resolving took: 00:00:00.3327755
18:58:39.3461 <4204> Updating the publish transaction with the list of processed items
18:58:39.3881 <4204> The number of processed items is zero, don't send an empty transport package

Try to explain this to the Business User: It shows success because it processed correctly every item that this publishing transaction was resolved to.

It is unfortunately not as easy to change this behavior as one would think (without performance impacts, which we all know is not what the Publishing Queue needs right now).

  • You send ItemX to the queue.
  • Publisher process picks it up
  • Resolver determines there's nothing to publish because of any reason and creates a List<ResolvedItem> with 0 items
  • Renderer loops through all items in the list, and there's no errors.
  • Transaction ends with # of errors = 0
  • Success

Nevertheless, this is something that we will try to address soon. It would also be incorrect to show it as a failure, because it did not fail, so probably a warning status with "There were no items to publish" message would be the better way to handle it.

Try to explain this to the Business User: It shows success because it processed correctly every item that this publishing transaction was resolved to.

It is unfortunately not as easy to change this behavior as one would think (without performance impacts, which we all know is not what the Publishing Queue needs right now).

  • You send ItemX to the queue.
  • Publisher process picks it up
  • Resolver determines there's nothing to publish because of any reason and creates a List<ResolvedItem> with 0 items
  • Renderer loops through all items in the list, and there's no errors.
  • Transaction ends with # of errors = 0
  • Success

Nevertheless, this is something that we will try to address soon. It would also be incorrect to show it as a failure, because it did not fail, so probably a warning status with "There were no items to publish" message would be the better way to handle it.

If you're curious, this is what the Resolver has to say about it:

18:58:39.0317 <4204> Using resolver [Tridion.ContentManager.Publishing.Resolving.StructureGroupResolver]
18:58:39.3256 <4204> Resolving the structure groups [tcm:5-350-4] took 00:00:00.2853292
18:58:39.3285 <4204> StructureGroup tcm:5-350-4 resolved to 0 items. Resolving took: 00:00:00.3327755
18:58:39.3461 <4204> Updating the publish transaction with the list of processed items
18:58:39.3881 <4204> The number of processed items is zero, don't send an empty transport package
Source Link
Nuno Linhares
  • 29.1k
  • 3
  • 42
  • 91

Try to explain this to the Business User: It shows success because it processed correctly every item that this publishing transaction was resolved to.

It is unfortunately not as easy to change this behavior as one would think (without performance impacts, which we all know is not what the Publishing Queue needs right now).

  • You send ItemX to the queue.
  • Publisher process picks it up
  • Resolver determines there's nothing to publish because of any reason and creates a List<ResolvedItem> with 0 items
  • Renderer loops through all items in the list, and there's no errors.
  • Transaction ends with # of errors = 0
  • Success

Nevertheless, this is something that we will try to address soon. It would also be incorrect to show it as a failure, because it did not fail, so probably a warning status with "There were no items to publish" message would be the better way to handle it.