Ref docs /// issue: CloudJob Class (Microsoft.Azure.Batch) Missing information about Bound/Unbound state of CloudJob

@marcelvb commented on Wed Apr 04 2018

Hi,

I have run into some issues with creating CloudJobs and CloudTasks from C#. I got errors such as:

System.InvalidOperationException: The property JobPreparationTask cannot be modified while the object is in the Bound state.
   at Microsoft.Azure.Batch.PropertyAccessor`1.SetValue(T value, Boolean overrideReadOnly, Boolean overrideAccessControl)

System.InvalidOperationException: The property State cannot be read while the object is in the Unbound state.
   at Microsoft.Azure.Batch.PropertyAccessController.ReadProperty[T](Func`1 propertyReadAction, BindingAccess allowedAccess, String propertyName)
   at Microsoft.Azure.Batch.CloudJob.get_State()

System.InvalidOperationException: This object is in an invalid state.  Write access is not allowed.
   at Microsoft.Azure.Batch.PropertyAccessor`1.<>c__DisplayClass19_0.<SetValue>b__0()
   at Microsoft.Azure.Batch.PropertyAccessor`1.SetValue(T value, Boolean overrideReadOnly, Boolean overrideAccessControl)

I’m confused when and when not I can read/write properties in relation to calls to:

• JobOperations.ListJobs()
• JobOperations.GetJob()
• JobOperations.CreateJob()
• Cloud.Job.Commit()
• Cloud.Job.CommitChanges()
• Cloud.Job.Refresh()

The errors thrown are not very helpful, nor is the documentation. Could you please clarify this subject a bit?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: ba097f44-6bcc-cb5a-208d-47db4415053e
• Version Independent ID: bafba85f-c12a-3396-aeee-71a3d08b8909
• Content: CloudJob Class (Microsoft.Azure.Batch)
• Content Source: xml/Microsoft.Azure.Batch/CloudJob.xml
• Service: batch
• GitHub Login: @erickson-doug
• Microsoft Alias: douge

[matthchr]

@CamSoper - Sorry for the slow response on this.

The short answer is that this is somewhat a limitation of the design of the “Object model” layer of the Azure Batch SDK. Because we re-use the same object (for example CloudJob) to control multiple REST API calls, it isn’t necessarily immediately clear what mutations to the CloudJob will/won’t be allowed to propagate to the server. That’s the reason why we have the exception related to bound/unbound state (so that at least you’ll get pushback at runtime when you try to update a property which cannot be updated). What I mean by that is, if for example you take a job and try to set the id property after doing a GetJob what you’re basically attempting to do is update the id field of an existing CloudJob in the Batch service, which isn’t allowed via the REST API.

There are a few short term workarounds for you:

1. If you’re just interested in figuring out which properties can/can’t be updated, you can go look at the documentation for the REST API itself, which maps 1-1 onto the properties you can/can’t change. So for example on a CloudJob after doing a GET you can only change properties which are “updatable” - which are listed here, specifically: constraints, metadata, onAllTasksComplete, poolInfo, priority
2. If you prefer, you can use the protocol API, which doesn’t have as many convienence features but which does make this particular issue clearer. That API is accessible in the namespace Microsoft.Azure.Batch.Protocol - see the BatchServiceClient there. It’s APIs aren’t based on objects but rather on functions, so you’ll see CloudJob job = batchServiceClient.GetJob() and then batchServiceClient.UpdateJob(constraints, onAllTasksComplete, poolInfo, priority).

Longer term action items for us:

1. We can just document in the /// comments which you can/can’t do. That’s pretty easy although I’m not sure it really solves the fundamental problem (can’t discover shape of API from shape of object clearly).
2. We could add an additional BatchClient.JobOperations.UpdateJob(constraints, onAllTasksComplete, poolInfo, priority) mirroring the one in the underlying protocol layer (and similarly for pool update/patch, etc). This doesn’t really solve the problem either, although it does at least give a concrete reference for what you can do in the Microsoft.Azure.Batch namespace. The bound/unbound exceptions would still be there if you chose to do update/patch via that mechanism though and tried something that wasn’t allowed.

I’ll discuss this internally with my team as well and see what people think. If you have a preference between 1 and 2 above (or a better idea/feature request) feel free to let us know.

[matthchr]

Closing this as there hasn’t been much action on it lately.