Only 1-st code run fails with Unspecified error 0x80004005 (?Inventor 2023 API defect?)

[Maxim-CADman77]

For last years I've faced several different cases of "Error 0x80004005" issue occur ONLY on the 1st run of some iLogic Rules* (I'm primarily focused on external rules), and I like to discuss here those cases and try to determine what unifies them and probably develop some common solution for this behavior.

"The most obvious" (easier to reproduce) Case #1 I'd like to start with was documented by MD_ about a year ago here - https://forums.autodesk.com/t5/inventor-ilogic-and-vb-net-forum/error-0x80004005-on-first-run/m-p/10...

I've tried to reanimate that thread without much success thus created this one (believe this is not any sort of forum rules violation).

I've created my own sample IPT (see attached) and modified original rule a bit in order to nail the issue to moment of processing the second Face:

Sub Main()

	Dim oFaces As Faces
	Dim oFace As Face

	oFaces = ThisDoc.Document.ComponentDefinition.SurfaceBodies(1).Faces
	
	' '[ Variant #1:
	' For Each oFace In oFaces
		' ThreadBuild(oFace)
	' Next
	' ']

	'[ Variant #2:
	For i=1 to 2
		oFace = oFaces(i)
		ThreadBuild(oFace)
	Next
	']

	' '[ Variant #3:
	' oFace = oFaces(1)
	' ThreadBuild(oFace)

	' oFace2 = oFaces(2)
	' ThreadBuild(oFace) ' No Error on 2nd run but doesn't create feature either
	' ']

End Sub


Sub ThreadBuild(oFace as Face)
	logger.debug(oFace.SurfaceType.ToString)
	Dim oTFs As ThreadFeatures = ThisDoc.Document.ComponentDefinition.Features.ThreadFeatures
	Dim oTF As ThreadFeature
	Dim oEdge As Edge
	Dim oThreadInfo As ThreadInfo
	Dim sThreadType As String

	If oFace.SurfaceType = kCylinderSurface ' Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))
		If oFace.ThreadInfos Is Nothing
			sThreadType = GetThreadTypeFromRadius(oFace.Geometry.Radius)
			If sThreadType<>String.Empty
				oEdge = oFace.Edges(1)
				oThreadInfo = oTFs.CreateStandardThreadInfo(True, True, "ISO Metric Profile", sThreadType, "6H")
				oTF = oTFs.Add(oFace, oEdge, oThreadInfo, False, True)
			End If
		End If
	End If
End Sub


Function GetThreadTypeFromRadius(dRadius As Double) As String
	Dim sThreadType As String
	logger.debug(Round(dRadius, 3))
	Select Round(dRadius, 3)
		Case 0.078
			sThreadType = "M2x0.4"
		Case 0.123
			sThreadType = "M3x0.5"
		Case 0.162
			sThreadType = "M4x0.7"
		Case 0.207
			sThreadType = "M5x0.8"
		Case 0.246
			sThreadType = "M6x1"
		Case 0.354
			sThreadType = "M8x1.25"
		Case 0.419
			sThreadType = "M10x1.5"
		Case 0.505
			sThreadType = "M12x1.75"
		Case 0.592
			sThreadType = "M14x2"
		Case 0.692
			sThreadType = "M16x2"
'		Case Else
'			Nothing
	End Select

	Return sThreadType
End Function

Pay attention there are three different ways to execute the things (feel free to have any one uncommented while playing around).

Any ideas of possible workaround?

* Whether you undo changes made by 1st run or just delete those changes manually, after you run the rule one more time -  things goes as smooth as expected to (except for Variant#3 which is a sub-issue to be explored).

But if you close the Inventor Document and reopen it - the issue become reproducible again.

I also found that "the rule" can run smoothly even on its 1st run if some other (relative) rule was run before it.

[Maxim-CADman77]

While waiting for some new inspiring* info I managed to create an inelegant workaround for the Case#1 based on assumption that all I need is the 2nd code run.

Now I run the Core-code (an external iLogic rule) with another "Wrapper" iLogic rule TWICE.

1-st run processes the 1-st FOR-cycle iteration and returns index of the item it failed on.
2-nd run starts from the point of the fail.

Thus at least I get things done with running code (wrapper-rule) just once.

Those interested can find result of my coding together with a sample part (Inventor 2022 and STP export for earlier versions) in the ZIP attached.

Yet I don't feel happy - I still need some official comment on this issue from some competent Autodesk person .. because it looks like ... an Inventor API defect, right?

* I was told that the issue (apart from iLogic) is reproducible in VBA and updating to Inventor 2023 doesn't solve it either.

I have no plans to re-check those statements myself yet I'm going to try to reproduce it in C#.

[MjDeck · Accepted solution]

Hi @Maxim-CADman77 , the error happens because when you add a feature the body is recalculated. After it's recalculated, the face references you got before are now stale. You have to get the body and faces again. This happens even though the thread feature doesn't add or remove faces. The body is still recalculated.

 Since the number and order of the faces doesn't change, you can just use the face index as a "persistent identifier". See the attached rule. If you were adding a feature that affected the number of faces, then you would need to use ReferenceKeys or Attributes to get a persistent ID.

[Maxim-CADman77]

@MjDeck 

Almost clear now.
The only question remained:
Why 2nd run used in my workaround did the trick for the given sample?

I would expect it to process correctly just 2nd face ... then 3rd run needed for 3rd face etc...

PS: I've marked the thread solved. I'll reopen it if I'll find that your explanation doesn't solve any other case I've mentioned earlier.

[MjDeck]

@Maxim-CADman77 , looks like I was wrong. The body is not recomputed every time. Something is done to it the first time, but I'm not sure what. In any case it looks like a defect.
It seems like creating the first feature initializes something in the body (or associated data). After that initialization, you have to get the body and faces again. After you get them again, it will succeed.

And the first feature does not have to remain in the part. I found that this works:

• open your 10-hole part
• Run a version of the rule with no error handling and no refresh of the faces collection. It will create one thread feature and then error out.
• Manually delete the new thread feature.
• Run the rule again. This time it will succeed and create features on all holes.

Here's a version of the rule that refreshes the faces collection only once: after it has created the first feature. This works.
I will look at this in more detail and probably create a bug for it. Please let me know if you find other cases like this.

[MjDeck · Accepted solution]

This is internal issue INVGEN-62312.