A script that used to work before is now behaving strangely.

[-_-]

I was using a script to rewrite the graded color labels with Arcpy, but it stopped working (maybe after I updated to 3.4.3).
I simplified the code and tested it, and the labels were set for just a moment, but then they went back to normal.
Is there something wrong with this code?

import arcpy

lyr="test"
tani="ha"

aprx=arcpy.mp.ArcGISProject("CURRENT")

view=aprx.activeView
mapname=view.map.name
maps=aprx.listMaps(mapname)[0]

l=maps.listLayers(lyr)[0]
label_count_last=l.symbology.renderer.breakCount

if hasattr(l.symbology, 'renderer'):
  if l.symbology.renderer.type == 'GraduatedColorsRenderer':
    sym = l.symbology
    sym.renderer.lowerBound = -10000000                 #3.4 lowerBound set on Renderer
    for i in range(0,label_count_last):
        brk=sym.renderer.classBreaks[i].upperBound
        sym.renderer.classBreaks[i].label=str(brk)+tani

    sym.renderer.classBreaks[-1].upperBound = 10000000 #upperBound set on upper ClassBreak
    l.symbology = sym

When executed:

[DanPatterson]

Do the classes stay in place is you drop the aprx.save()?

The code examples in the help use aprx.saveas or there is no saving.

[-_-]

Removing aprx.save() doesn't change the result.

[DanPatterson]

GraduatedColorsRenderer—ArcGIS Pro | Documentation

which leaves the lower bound statement

(Read and Write)
A double that represents the minimum value of the symbolized classificationField to be displayed.

Note:
The value of the lowerBound should only be set to a value within the range of the first class break, otherwise it will fail. The maximum value gets modified in the last class break by changing the upperBound property.

[-_-]

The original code included code to set upper and lower limits, but this has now been removed in order to identify the cause.

Does this code work as intended in your environment?

[David_Lindsey]

OP, what version of Pro did you upgrade from when you jumped to 3.4.3?

[-_-]

I think it was around 3.4.1.
However, when I upgraded to 3.4, various other problems occurred, so I can't clearly remember whether this problem was there at the time and I didn't notice it, or whether it started occurring when I upgraded to 3.4.3.

[David_Lindsey]

Unless this is you in the comment section of this Reddit post, you may not be the only one experiencing this issue recently. In my experience with minor releases (and given how much symbology-related stuff that Esri touched with the 3.4 release), I wouldn't rule out a bug being introduced. No mention of deprecations related to your issue in the release notes either. I use aprx.save() with my symbology updates as well, but haven't been doing the same workflows that you are doing.  It does look like you are running the code while Pro is open though. Do the edits save correctly if you run the script as a standalone while Pro is closed? That test might help you rule out a lock or read-only issue...maybe. Oh, and be sure to save a copy of your project beforehand if you try anything as a standalone. I learned that lesson the hard way. Ha.

[-_-]

Sorry, I've always used the scripts in the toolbox and don't know how to run them standalone.

[-_-]

I still don't know why the original code was causing the problem, but I was able to use CIM access to rewrite the label.

import arcpy

lyr="test"
tani="ha"

aprx=arcpy.mp.ArcGISProject("CURRENT")

view=aprx.activeView
mapname=view.map.name
maps=aprx.listMaps(mapname)[0]

l=maps.listLayers(lyr)[0]
label_count_last=l.symbology.renderer.breakCount

if hasattr(l.symbology, 'renderer'):
  if l.symbology.renderer.type == 'GraduatedColorsRenderer':

    l_cim=l.getDefinition('V3')
    l_cim.renderer.minimumBreak = -10000000

    for i in range(0,label_count_last):
        brk=l_cim.renderer.breaks[i].upperBound
        l_cim.renderer.breaks[i].label=str(brk)+tani

    l_cim.renderer.breaks[-1].upperBound = 10000000
    l.setDefinition(l_cim)