Problem with GenerateRendererTask() and setLayerDefinitions() 10.4

[ErikMyers]

Hi There,

I'm using the JS API v.3.20 GenerateRendererTask() and ClassBreaksDefinition() to render classes and allow the user to customize the map data.  It works fine for the entire layer, but as soon as I set layer definitions the map does not export properly.  The renderer appears to be working because the classes are set correctly in the legend with the correct symbols applied.  The strange thing is that if I change to a simpleRenderer, I can render a custom symbol on the map and in the legend.  I need it to work with class breaks though.

I've been struggling with this for some time now.  Here is a link to a js fiddle from a customized esri sample.  Uncomment the block at line 103 to see how setting layerDefinitions breaks the map output.   Edit fiddle - JSFiddle 

I also attached the html file.  Can anyone explain why the full layer renders properly, but a subset of the layer does not?  Myself and entire team have tried multiple variations and are stumped!

Thanks!

[KristianEkenes]

I suggest trying the SmartMapping API to achieve this. Here's a sample showing how to generate class breaks: Smart Mapping - Render class breaks with color | ArcGIS API for JavaScript 3.20 

Since it looks like you're using dynamic layers, you can construct a FeatureLayer from one of the sublayers to generate the renderer and apply it to the drawingInfo of the layer. That is the pattern used in this blog: Smart Mapping with dynamic workspaces | ArcGIS Blog 

On a side note, the 4.x API will eventually remove the need for creating a FeatureLayer and allow you to directly reference the sublayer, making this process a lot simpler. Hope that helps!

[ErikMyers · Accepted solution]

Hi and thanks for the reply.  Unfortunately, I won't be able to use FeatureLayer because I need to render and display hundreds of thousands of features in (near) future versions of this app.  I will add some interesting information that our team uncovered in the meantime. 

We found that the the renderer was correct and that an image was being exported from the server, but as f: "JSON" instead of f: "image".  There was also inconsistency about whether the request was a GET or POST.  This error was only occurring when the where clause was included in the request so we suspected it to be a bug in the API.  We decided to try some different settings on the server side to see if we could get the correct image response.  

In the end, we changed the Anti-Aliasing service Parameter from "None" to "Fastest" and the issue seems to have been resolved for now.