Error: One or more checkpoints could not be created

[Alan Birchenough]

I am on IJ 2022.1 and IC2 2.2.1.8.

I get this error when trying to set an Apex Checkpoint in the source editor:

DUPLICATE_VALUE - duplicate value found: ScopeId duplicates value on record with id: 1do75000000GnyH

Also, if I try to use a local breakpoint instead, nothing happens. The transaction runs from beginning to end without breaking. The first step in the debugger (before hitting “Run”) seems to land in some meaningless code location.

Sorry to seem vague; I get this a fair amount, and behavior is not always exactly the same.

I have already tried invalidating caches and restarting.

Sorry if this is a dupe. I couldn’t seem to find anything similar. If you want me to collect collateral, please advise. I guess you will want a log, but not sure what settings, etc., you would like.

‌

[Scott Wells]

Let's separate these two issues since they're likely unrelated. Let's start with the DUPLICATE_VALUE error and see what checkpoints are already registered. Please run the following SOQL query using the Tooling API:

SELECT
    Id,
    IsDeleted,
    IsDumpingHeap,
    Iteration,
    LastModifiedById,
    LastModifiedDate,
    Line,
    ScopeId,
    Scope.Username
FROM ApexExecutionOverlayAction
ORDER BY ScopeId

I'm assuming that you're user ID 1do75000000GnyH, so let's focus on rows for that and see why it might be failing with a duplicate. You're certainly allowed to have multiple checkpoints per-user...up to 5, I think, so I'm not sure what would result in a dupe.

As for a local breakpoint not stopping execution, it's hard to say. The main times I see that happen are when the underlying log doesn't ever actually include execution at that line number for some reason...perhaps the log is too large, or I've ever seen some logs under 20MB that just don't include the correct level of info. I hate to say it, but the best way for me to be able to debug it would be if you could reproduce it in an environment that could be shared, i.e., not against proprietary stuff.

[Alan Birchenough]

Thanks. I agree with the idea of separating the issues. Doing so would help me prepare better information on the other aspect (ineffective breaks), then I can raise a separate ticket when/if necessary.

I hope to be able to respond regarding the checkpoints during the course of today.

[Alan Birchenough]

The attached is what I got when I ran that query. Currently it is the 1do75000000Go1kAAC Id that the error is complaining about, which makes sense because I was trying to add a checkpoint at line 61.

BTW, I don't know what is going on with BitBucket UI, but I was able to paste these results very prettily into the rich text box, but upon saving, the table data was just completely thrown away. I looked for "preview" so I could see if I got the markup right, but that function no longer seems to exist. Ho hum. That's why I ended up posting an attachment.

[Alan Birchenough]

More on this: Your suggestion to perform the tooling api query reminded me that checkpoint status can be accessed via the Developer Console. I observed that that same checkpoints that showed up in the query you sent me also showed up in the Console, except that only those associated with my user were included. I then used “Clear Checkpoint Locations”, and all the entries against my user name in the checkpoint list disappeared. On returning to IC2, I was able to click in the gutter and request a new checkpoint, but it once again failed during the commencement of the next debug test run, with the same error message as before, even though there were no pre-existing checkpoints visible in the Developer Console before clicking, and just the one visible on commencing the debug test run right after the click.

Let me know if I can provide any further useful information.

Thanks.

[Scott Wells]

Alan, when IC2 runs tests it resets the user's registered checkpoints to model the project's locally-established checkpoint/server breakpoints. Unfortunately there's not very good debug logging in that specific area, but it should still be possible to see what's going on when this happens by enabling the following for debug logging in Help>Diagnostic Tools>Debug Log Settings:

#com.illuminatedcloud.client.ForceComApiClient
#com.illuminatedcloud.client.ForceComApiClient!trace

A few things to note about that level of logging:

1. You'll need to restart the IDE because the latter isn't picked up until the API client is recreated/reinitialized.
2. ALL client/server API requests/responses will be logged including credentials in logins to native connections, so you'll want to scrub any log extract you provide for sensitive info.

What I'll be looking at in the resulting log will be the results of several calls to the Tooling API to query existing checkpoints, remove those checkpoints, and create new checkpoints based on the local config.

Let me know if you have any issues creating such a log.

[Alan Birchenough]

Thanks. I will continue to pursue this issue as I may so we can get to a conclusion on it. Unfortunately I am not going to get the chance to single thread on it, so if a couple of days go by between posts, it doesn’t mean that anything has gone wrong.

[Alan Birchenough]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Alan Birchenough]

I attached logs as requested. I have no idea what I am looking at, so I could not scrub them. I was using an SFDX login, so hopefully that does not expose anything sensitive as far as credentials go.

My most recent attempt to set an Apex checkpoint was on line 36 of FfContractCrApplicationEventPublisher. The setting interaction itself went fine, but the usual error dialog (as shown previously) was posted when I tried to run the test in debug mode.

I then tried to use a local breakpoint instead. The test started up and jumped into a random position within the test setup itself. On hitting continue, the whole test ended without stopping anywhere. Sometimes I have to run my tests in VSCode to get around this problem.

[Alan Birchenough]

We said we’d separate off the discussion about the non-breakpointing behavior I am seeing in debugging tests, so I am going to create a separate ticket. It appears to be caused by some issue with setting trace flags.

[Scott Wells]

Okay, based on the provided debug log, it looks like it's not properly clearing existing checkpoints before trying to (re)create them. I can see the SOAP call to create them which results in "duplicate value found", and before that I'd expect to see a query for existing checkpoints but do not. Instead the previous request is the one for the Apex class ID of the class that contains the checkpoint. There are 1-2 calls in between that should technically have executed, and the only reason they wouldn't is if the current connection user's ID couldn't be discerned from the queried UserInfo.

I'm going to instrument this all with additional debug logging for Thursday's build and will then tell you how to enable that debug logging so we can get a more definitive debug log to confirm that suspicion.

[Scott Wells]

Okay, I instrumented this area with pretty extensive debug logging. Please install the attached build (same as 2.2.2.0 except for the additional logging) by downloading the archive (don't extract it) and using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down). Then restart the IDE, add the following to your debug log settings:

#com.illuminatedcloud.intellij.debugger.ApexOfflineDebuggerBreakpointRegistrar

and reproduce the issue. Provide the resulting logs and hopefully they'll shine a bright light on whatever is happening.

[Alan Birchenough]

Thanks. Just a quick note: I have not had a chance to work in that particular org for a few days, but once I get back in there later this week, I will push ahead with this. (I only get the problem in that one org.) And in fact, that's not the only API-related problem I am having there. I also have trouble setting trace flags from the IDE, which explains why my test debug runs don't respect breakpoints - there is not enough log information for the debugger to go on.

I may or may not raise an issue for the trace flag problem. First things first though. I will take care of this one before raising another ticket.

Thanks again.

[Alan Birchenough]

Attached is the log after attempting to set an Apex server checkpoint on line 114 of FfContractLineItemOliLookupHandler. Once I got the error dialog about the duplicate checkpoint, I did not take the scenario any further. I don't think that actually running the test in debug mode would have provided any further useful information.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.