Is MIXED_DML_OPERATION in unit tests broken?












9















We have a nightly integration that runs all tests and reports any errors against production, currently on Winter '19. Everything was fine until January 14th, 2019, when 13 previously passing tests started to fail with MIXED_DML_OPERATION exceptions. The exact same tests are passing in my Spring '19 sandbox. I created a new demonstration class in my Developer Org, which is also Winter '19, and the tests are passing there, too. Is there a documented change on MIXED_DML_OPERATION, or is a bug being fixed?





@isTest class MixedDMLError {
@isTest static void test() {
User u = [select Email, TimezoneSidKey, LocaleSidkey, LastName, EmailEncodingKey, ProfileId, LanguageLocaleKey from user where id = :UserInfo.getUserId()];
u = u.clone(false);
u.username = 'user'+math.random()+'@org.random';
u.alias = (math.random()+'').remove('.').left(8);
insert u;
Account a = new Account(Name=Math.random()+'');
insert a;
}
}




Edit



It has been mentioned that UserRoleId might be the culprit, so I checked the source code. Here's the actual method creating the user:



public static User createUser( String profileName,String usrName, Boolean doInsert){
Profile pro =[SELECT Id From Profile WHERE Name = :profileName];
User usr = new user(
FirstName='USR_FN',
LastName='USR_LN',
Username=usrName,
ProfileId=pro.Id,
email='example@example.com',
emailencodingkey='UTF-8',
languagelocalekey='en_US',
localesidkey='en_US',
timezonesidkey='America/Los_Angeles',
alias='USR_FN'.substring(0,1)+'USR_LN'.substring(0,1)+string.valueof( Math.random()).substring(0,3)
);

if(doInsert)
insert usr;

return usr;
}


The role is left null, so unfortunately, that does not explain the difference. Both the unit test and the utility class it calls are identical in the Sandboxes I've tested and Production.





Edit 2



This problem only occurs when running tests. During deployments/validations using Run All Tests or Run Specified Tests, the operation succeeds without any errors. This appears to be a bug in how tests are run.










share|improve this question




















  • 2





    I had the same thing happen a few releases back - Mixed DML that was previously working just stopped. Salesforce wasn't helpful and we ended up having to rewrite the test class, which was something that needed done anyway

    – brezotom
    Jan 15 at 2:17











  • @brezotom Yeah, this seems off though--the documentation doesn't match the behavior, so something needs to be fixed either way.

    – sfdcfox
    Jan 15 at 3:55











  • Just wanted to say I am facing the same exact issue.

    – Bryan Anderson
    Jan 16 at 19:14


















9















We have a nightly integration that runs all tests and reports any errors against production, currently on Winter '19. Everything was fine until January 14th, 2019, when 13 previously passing tests started to fail with MIXED_DML_OPERATION exceptions. The exact same tests are passing in my Spring '19 sandbox. I created a new demonstration class in my Developer Org, which is also Winter '19, and the tests are passing there, too. Is there a documented change on MIXED_DML_OPERATION, or is a bug being fixed?





@isTest class MixedDMLError {
@isTest static void test() {
User u = [select Email, TimezoneSidKey, LocaleSidkey, LastName, EmailEncodingKey, ProfileId, LanguageLocaleKey from user where id = :UserInfo.getUserId()];
u = u.clone(false);
u.username = 'user'+math.random()+'@org.random';
u.alias = (math.random()+'').remove('.').left(8);
insert u;
Account a = new Account(Name=Math.random()+'');
insert a;
}
}




Edit



It has been mentioned that UserRoleId might be the culprit, so I checked the source code. Here's the actual method creating the user:



public static User createUser( String profileName,String usrName, Boolean doInsert){
Profile pro =[SELECT Id From Profile WHERE Name = :profileName];
User usr = new user(
FirstName='USR_FN',
LastName='USR_LN',
Username=usrName,
ProfileId=pro.Id,
email='example@example.com',
emailencodingkey='UTF-8',
languagelocalekey='en_US',
localesidkey='en_US',
timezonesidkey='America/Los_Angeles',
alias='USR_FN'.substring(0,1)+'USR_LN'.substring(0,1)+string.valueof( Math.random()).substring(0,3)
);

if(doInsert)
insert usr;

return usr;
}


The role is left null, so unfortunately, that does not explain the difference. Both the unit test and the utility class it calls are identical in the Sandboxes I've tested and Production.





Edit 2



This problem only occurs when running tests. During deployments/validations using Run All Tests or Run Specified Tests, the operation succeeds without any errors. This appears to be a bug in how tests are run.










share|improve this question




















  • 2





    I had the same thing happen a few releases back - Mixed DML that was previously working just stopped. Salesforce wasn't helpful and we ended up having to rewrite the test class, which was something that needed done anyway

    – brezotom
    Jan 15 at 2:17











  • @brezotom Yeah, this seems off though--the documentation doesn't match the behavior, so something needs to be fixed either way.

    – sfdcfox
    Jan 15 at 3:55











  • Just wanted to say I am facing the same exact issue.

    – Bryan Anderson
    Jan 16 at 19:14
















9












9








9








We have a nightly integration that runs all tests and reports any errors against production, currently on Winter '19. Everything was fine until January 14th, 2019, when 13 previously passing tests started to fail with MIXED_DML_OPERATION exceptions. The exact same tests are passing in my Spring '19 sandbox. I created a new demonstration class in my Developer Org, which is also Winter '19, and the tests are passing there, too. Is there a documented change on MIXED_DML_OPERATION, or is a bug being fixed?





@isTest class MixedDMLError {
@isTest static void test() {
User u = [select Email, TimezoneSidKey, LocaleSidkey, LastName, EmailEncodingKey, ProfileId, LanguageLocaleKey from user where id = :UserInfo.getUserId()];
u = u.clone(false);
u.username = 'user'+math.random()+'@org.random';
u.alias = (math.random()+'').remove('.').left(8);
insert u;
Account a = new Account(Name=Math.random()+'');
insert a;
}
}




Edit



It has been mentioned that UserRoleId might be the culprit, so I checked the source code. Here's the actual method creating the user:



public static User createUser( String profileName,String usrName, Boolean doInsert){
Profile pro =[SELECT Id From Profile WHERE Name = :profileName];
User usr = new user(
FirstName='USR_FN',
LastName='USR_LN',
Username=usrName,
ProfileId=pro.Id,
email='example@example.com',
emailencodingkey='UTF-8',
languagelocalekey='en_US',
localesidkey='en_US',
timezonesidkey='America/Los_Angeles',
alias='USR_FN'.substring(0,1)+'USR_LN'.substring(0,1)+string.valueof( Math.random()).substring(0,3)
);

if(doInsert)
insert usr;

return usr;
}


The role is left null, so unfortunately, that does not explain the difference. Both the unit test and the utility class it calls are identical in the Sandboxes I've tested and Production.





Edit 2



This problem only occurs when running tests. During deployments/validations using Run All Tests or Run Specified Tests, the operation succeeds without any errors. This appears to be a bug in how tests are run.










share|improve this question
















We have a nightly integration that runs all tests and reports any errors against production, currently on Winter '19. Everything was fine until January 14th, 2019, when 13 previously passing tests started to fail with MIXED_DML_OPERATION exceptions. The exact same tests are passing in my Spring '19 sandbox. I created a new demonstration class in my Developer Org, which is also Winter '19, and the tests are passing there, too. Is there a documented change on MIXED_DML_OPERATION, or is a bug being fixed?





@isTest class MixedDMLError {
@isTest static void test() {
User u = [select Email, TimezoneSidKey, LocaleSidkey, LastName, EmailEncodingKey, ProfileId, LanguageLocaleKey from user where id = :UserInfo.getUserId()];
u = u.clone(false);
u.username = 'user'+math.random()+'@org.random';
u.alias = (math.random()+'').remove('.').left(8);
insert u;
Account a = new Account(Name=Math.random()+'');
insert a;
}
}




Edit



It has been mentioned that UserRoleId might be the culprit, so I checked the source code. Here's the actual method creating the user:



public static User createUser( String profileName,String usrName, Boolean doInsert){
Profile pro =[SELECT Id From Profile WHERE Name = :profileName];
User usr = new user(
FirstName='USR_FN',
LastName='USR_LN',
Username=usrName,
ProfileId=pro.Id,
email='example@example.com',
emailencodingkey='UTF-8',
languagelocalekey='en_US',
localesidkey='en_US',
timezonesidkey='America/Los_Angeles',
alias='USR_FN'.substring(0,1)+'USR_LN'.substring(0,1)+string.valueof( Math.random()).substring(0,3)
);

if(doInsert)
insert usr;

return usr;
}


The role is left null, so unfortunately, that does not explain the difference. Both the unit test and the utility class it calls are identical in the Sandboxes I've tested and Production.





Edit 2



This problem only occurs when running tests. During deployments/validations using Run All Tests or Run Specified Tests, the operation succeeds without any errors. This appears to be a bug in how tests are run.







apex unit-test bug






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 14 at 23:38







sfdcfox

















asked Jan 14 at 21:45









sfdcfoxsfdcfox

251k11193431




251k11193431








  • 2





    I had the same thing happen a few releases back - Mixed DML that was previously working just stopped. Salesforce wasn't helpful and we ended up having to rewrite the test class, which was something that needed done anyway

    – brezotom
    Jan 15 at 2:17











  • @brezotom Yeah, this seems off though--the documentation doesn't match the behavior, so something needs to be fixed either way.

    – sfdcfox
    Jan 15 at 3:55











  • Just wanted to say I am facing the same exact issue.

    – Bryan Anderson
    Jan 16 at 19:14
















  • 2





    I had the same thing happen a few releases back - Mixed DML that was previously working just stopped. Salesforce wasn't helpful and we ended up having to rewrite the test class, which was something that needed done anyway

    – brezotom
    Jan 15 at 2:17











  • @brezotom Yeah, this seems off though--the documentation doesn't match the behavior, so something needs to be fixed either way.

    – sfdcfox
    Jan 15 at 3:55











  • Just wanted to say I am facing the same exact issue.

    – Bryan Anderson
    Jan 16 at 19:14










2




2





I had the same thing happen a few releases back - Mixed DML that was previously working just stopped. Salesforce wasn't helpful and we ended up having to rewrite the test class, which was something that needed done anyway

– brezotom
Jan 15 at 2:17





I had the same thing happen a few releases back - Mixed DML that was previously working just stopped. Salesforce wasn't helpful and we ended up having to rewrite the test class, which was something that needed done anyway

– brezotom
Jan 15 at 2:17













@brezotom Yeah, this seems off though--the documentation doesn't match the behavior, so something needs to be fixed either way.

– sfdcfox
Jan 15 at 3:55





@brezotom Yeah, this seems off though--the documentation doesn't match the behavior, so something needs to be fixed either way.

– sfdcfox
Jan 15 at 3:55













Just wanted to say I am facing the same exact issue.

– Bryan Anderson
Jan 16 at 19:14







Just wanted to say I am facing the same exact issue.

– Bryan Anderson
Jan 16 at 19:14












2 Answers
2






active

oldest

votes


















4














Likely not a bug. Note from the documentation on sObjects That Cannot Be Used Together in DML Operations:




You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if UserRoleId is specified as null.




Your unit test does not filter on this field, nor clear it out before inserting the clone.



If you are going to create a User record by cloning the running user, make sure to set UserRoleId = null before your insert call.



If you do not do so, test runs will not behave the same for each user who runs them, or if certain attributes on that user change.






share|improve this answer
























  • The real code does not use a query, actually; you'll want to see my edit.

    – sfdcfox
    Jan 14 at 22:27











  • Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

    – Adrian Larson
    Jan 14 at 22:29











  • But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

    – Avijit Chakraborty
    Jan 15 at 3:13











  • Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

    – Adrian Larson
    Jan 15 at 3:17



















0














You can not update account and user in same transaction. Are you sure that it was working previously or you added some field while retrieving user?



This is the documentation reference https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm



You can update a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if the following fields are not also updated:




  • UserRoleId

  • IsActive

  • ForecastEnabled

  • IsPortalEnabled

  • Username

  • ProfileId


Please try removing profile id and see the results, moreover you need not to insert user to do a runAs you can pass the user if you need to test based on profile






share|improve this answer



















  • 4





    Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

    – sfdcfox
    Jan 14 at 22:03













  • You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

    – Avijit Chakraborty
    Jan 14 at 22:04













  • @AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

    – Pranay Jaiswal
    Jan 14 at 22:10













  • If you put different code how anybody can answer we both redirected you so same link.

    – Avijit Chakraborty
    Jan 15 at 3:15










protected by Adrian Larson 10 hours ago



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?














2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














Likely not a bug. Note from the documentation on sObjects That Cannot Be Used Together in DML Operations:




You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if UserRoleId is specified as null.




Your unit test does not filter on this field, nor clear it out before inserting the clone.



If you are going to create a User record by cloning the running user, make sure to set UserRoleId = null before your insert call.



If you do not do so, test runs will not behave the same for each user who runs them, or if certain attributes on that user change.






share|improve this answer
























  • The real code does not use a query, actually; you'll want to see my edit.

    – sfdcfox
    Jan 14 at 22:27











  • Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

    – Adrian Larson
    Jan 14 at 22:29











  • But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

    – Avijit Chakraborty
    Jan 15 at 3:13











  • Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

    – Adrian Larson
    Jan 15 at 3:17
















4














Likely not a bug. Note from the documentation on sObjects That Cannot Be Used Together in DML Operations:




You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if UserRoleId is specified as null.




Your unit test does not filter on this field, nor clear it out before inserting the clone.



If you are going to create a User record by cloning the running user, make sure to set UserRoleId = null before your insert call.



If you do not do so, test runs will not behave the same for each user who runs them, or if certain attributes on that user change.






share|improve this answer
























  • The real code does not use a query, actually; you'll want to see my edit.

    – sfdcfox
    Jan 14 at 22:27











  • Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

    – Adrian Larson
    Jan 14 at 22:29











  • But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

    – Avijit Chakraborty
    Jan 15 at 3:13











  • Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

    – Adrian Larson
    Jan 15 at 3:17














4












4








4







Likely not a bug. Note from the documentation on sObjects That Cannot Be Used Together in DML Operations:




You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if UserRoleId is specified as null.




Your unit test does not filter on this field, nor clear it out before inserting the clone.



If you are going to create a User record by cloning the running user, make sure to set UserRoleId = null before your insert call.



If you do not do so, test runs will not behave the same for each user who runs them, or if certain attributes on that user change.






share|improve this answer













Likely not a bug. Note from the documentation on sObjects That Cannot Be Used Together in DML Operations:




You can insert a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if UserRoleId is specified as null.




Your unit test does not filter on this field, nor clear it out before inserting the clone.



If you are going to create a User record by cloning the running user, make sure to set UserRoleId = null before your insert call.



If you do not do so, test runs will not behave the same for each user who runs them, or if certain attributes on that user change.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 14 at 22:11









Adrian LarsonAdrian Larson

106k19113241




106k19113241













  • The real code does not use a query, actually; you'll want to see my edit.

    – sfdcfox
    Jan 14 at 22:27











  • Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

    – Adrian Larson
    Jan 14 at 22:29











  • But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

    – Avijit Chakraborty
    Jan 15 at 3:13











  • Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

    – Adrian Larson
    Jan 15 at 3:17



















  • The real code does not use a query, actually; you'll want to see my edit.

    – sfdcfox
    Jan 14 at 22:27











  • Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

    – Adrian Larson
    Jan 14 at 22:29











  • But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

    – Avijit Chakraborty
    Jan 15 at 3:13











  • Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

    – Adrian Larson
    Jan 15 at 3:17

















The real code does not use a query, actually; you'll want to see my edit.

– sfdcfox
Jan 14 at 22:27





The real code does not use a query, actually; you'll want to see my edit.

– sfdcfox
Jan 14 at 22:27













Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

– Adrian Larson
Jan 14 at 22:29





Yeah makes more sense now. Do you have any triggers or workflows which might be setting UserRoleId inadvertently? Hopefully not in a managed package...

– Adrian Larson
Jan 14 at 22:29













But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

– Avijit Chakraborty
Jan 15 at 3:13





But the documentation also says you cannot update profile id and other object in same transaction. UserRoleId no where mentioned in the code role can be blank in user so my thought is profile id is causing mixed DML

– Avijit Chakraborty
Jan 15 at 3:13













Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

– Adrian Larson
Jan 15 at 3:17





Your assessment seems off base. There is only an insert statement. The passage you cite above mentions update only. Seems quite likely irrelevant.

– Adrian Larson
Jan 15 at 3:17













0














You can not update account and user in same transaction. Are you sure that it was working previously or you added some field while retrieving user?



This is the documentation reference https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm



You can update a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if the following fields are not also updated:




  • UserRoleId

  • IsActive

  • ForecastEnabled

  • IsPortalEnabled

  • Username

  • ProfileId


Please try removing profile id and see the results, moreover you need not to insert user to do a runAs you can pass the user if you need to test based on profile






share|improve this answer



















  • 4





    Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

    – sfdcfox
    Jan 14 at 22:03













  • You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

    – Avijit Chakraborty
    Jan 14 at 22:04













  • @AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

    – Pranay Jaiswal
    Jan 14 at 22:10













  • If you put different code how anybody can answer we both redirected you so same link.

    – Avijit Chakraborty
    Jan 15 at 3:15
















0














You can not update account and user in same transaction. Are you sure that it was working previously or you added some field while retrieving user?



This is the documentation reference https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm



You can update a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if the following fields are not also updated:




  • UserRoleId

  • IsActive

  • ForecastEnabled

  • IsPortalEnabled

  • Username

  • ProfileId


Please try removing profile id and see the results, moreover you need not to insert user to do a runAs you can pass the user if you need to test based on profile






share|improve this answer



















  • 4





    Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

    – sfdcfox
    Jan 14 at 22:03













  • You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

    – Avijit Chakraborty
    Jan 14 at 22:04













  • @AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

    – Pranay Jaiswal
    Jan 14 at 22:10













  • If you put different code how anybody can answer we both redirected you so same link.

    – Avijit Chakraborty
    Jan 15 at 3:15














0












0








0







You can not update account and user in same transaction. Are you sure that it was working previously or you added some field while retrieving user?



This is the documentation reference https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm



You can update a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if the following fields are not also updated:




  • UserRoleId

  • IsActive

  • ForecastEnabled

  • IsPortalEnabled

  • Username

  • ProfileId


Please try removing profile id and see the results, moreover you need not to insert user to do a runAs you can pass the user if you need to test based on profile






share|improve this answer













You can not update account and user in same transaction. Are you sure that it was working previously or you added some field while retrieving user?



This is the documentation reference https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm



You can update a user in a transaction with other sObjects in Apex code saved using Salesforce API version 15.0 and later if the following fields are not also updated:




  • UserRoleId

  • IsActive

  • ForecastEnabled

  • IsPortalEnabled

  • Username

  • ProfileId


Please try removing profile id and see the results, moreover you need not to insert user to do a runAs you can pass the user if you need to test based on profile







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 14 at 21:59









Avijit ChakrabortyAvijit Chakraborty

1,2601515




1,2601515








  • 4





    Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

    – sfdcfox
    Jan 14 at 22:03













  • You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

    – Avijit Chakraborty
    Jan 14 at 22:04













  • @AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

    – Pranay Jaiswal
    Jan 14 at 22:10













  • If you put different code how anybody can answer we both redirected you so same link.

    – Avijit Chakraborty
    Jan 15 at 3:15














  • 4





    Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

    – sfdcfox
    Jan 14 at 22:03













  • You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

    – Avijit Chakraborty
    Jan 14 at 22:04













  • @AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

    – Pranay Jaiswal
    Jan 14 at 22:10













  • If you put different code how anybody can answer we both redirected you so same link.

    – Avijit Chakraborty
    Jan 15 at 3:15








4




4





Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

– sfdcfox
Jan 14 at 22:03







Yes, I know about System.runAs, and I've advised our team that we need to clean up the code. But we have logs showing successful nightly runs until this morning at about 3am MST (America/Denver). Further, the test in the question is passing in a Winter '19 Developer Org and a Spring '19 Sandbox Org. We've been doing deployments twice a week without any problems until today. Our diffs show no changes at all to those classes in months, either, they just started failing.

– sfdcfox
Jan 14 at 22:03















You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

– Avijit Chakraborty
Jan 14 at 22:04







You need to remove the profile ID, request you to see the documentation. why you need the profile id in the soql if you are not using

– Avijit Chakraborty
Jan 14 at 22:04















@AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

– Pranay Jaiswal
Jan 14 at 22:10







@AvijitChakraborty it works in Winter 19, so it's not a code issue and SF issue. The code provided by sfdcfox is pseudo code.

– Pranay Jaiswal
Jan 14 at 22:10















If you put different code how anybody can answer we both redirected you so same link.

– Avijit Chakraborty
Jan 15 at 3:15





If you put different code how anybody can answer we both redirected you so same link.

– Avijit Chakraborty
Jan 15 at 3:15





protected by Adrian Larson 10 hours ago



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?



Popular posts from this blog

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?