If the reader isn’t bringing in all the features to begin with, I don’t believe the FeatureHolder would help. Are there any filters on the Portal feature layer by default? I seem to remember running into something similar years ago, where after an update to FME or ArcGIS Portal, FME was honoring the default filter on an ArcGIS Portal layer. Alternatively, if you have a newer version of FME, there is a new Esri ArcGIS Feature Service Reader that you could try.

Thanks ​@paul_m, I don’t think it’s a filter issue as the workspace ran correctly the run before and the run after with the exact same data. So it was just a weird one-off incident where it didn’t read everything in.

I noticed in the log there is a metadata section that gives the number of records in the table.

This is for “Reader 1” (the one that glitched) but it is showing the correct number of records in the metadata section:

INFORM|ArcGIS Portal Feature Service Reader: Requesting metadata for Feature Service at <URL>
INFORM|ArcGIS Portal Feature Service Reader: Found layer/table <Table Name> with ID <##> for feature type <Table>
INFORM|ArcGIS Portal Feature Service Reader: Requesting metadata for layer/table <##> of Feature Service at <URL>
INFORM|ArcGIS Portal Feature Service Reader: Querying layer/table <##> for object IDs, where '1=1'
INFORM|ArcGIS Portal Feature Service Reader: Got 444416 results for layer/table ID <##>

And lower down it shows the total number of records read in from all of the readers.

(wrong number read in, the total should have been 888832 as both tables had 444416 records):

|INFORM|MULTI_READER(MULTI_READER): Done reading 888085 features from 2 readers

And then in the summary it again shows that “Reader 1” read in less than the number of records than what the metadata was saying existed in the table:

|STATS |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|STATS |                            Features Read Summary
|STATS |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|STATS |<Reader 1>                                                              443669
|STATS |<Reader 2>                                                              444416
|STATS |==============================================================================
|STATS |Total Features Read                                                     888085
|STATS |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

So I was hoping the feature holder would make sure that the workspace doesn’t continue until all records were read in since the metadata section is showing the correct number of records. But I don’t know how to verify if this will work or not.

Ok, FeatureHolder does not solve this problem. I have had the issue occur on a workbench with feature holders after the readers.

Still don’t know what is causing the underlying issue as the workspace ran correctly before and after it didn’t.

Also, just in case someone comes across this thread in the future, if it’s a sporadic issue like mine, this temporary workaround might help until you can fix the cause of the issue:

• HTTPCaller to get the record count for the table
• StatisticsCalculator to get the count of records read in from the reader
• Tester to compare if those numbers the same
• Terminator to kill the workbench if the numbers don’t match