Incidentally, there is no type check to ensure that the output of serving_input_receiver_fn is a ServingInputReceiver.

(Not that there should be one. It would be pretty annoying.)

@fchollet, @martinwicke, do you have any thoughts on how this should be handled?

@nkashy1

From my understanding of export_savedmodel on custom models you will need to work with feature dicts for the export to work.

I came across this same issue as I just pass tensors to the model. So what I did was check to see what type of features are being passed in (straight tensors or dict of features). If it is just tensors, do the normal code. If it is the features dict, then I convert it to tensors using input_from_feature_columns.

logits = features
if type(features) is dict:
            input_layer = tensorflow.contrib.layers.input_from_feature_columns(features, self.feature_columns)
            logits = input_layer

@michaelpetruzzellocivicom : That's right, you need feature dictionaries in your custom estimator as ServingInputReceiver is implemented, but the documentation for input_fn + model_fn claims that it can be bare tensors or feature dictionaries.

Although one can convert to single tensor the way you did above, and also directly, the point is that the API is inconsistent. Either the API needs to be changed (so that input_fn and model_fn are no longer expected to take bare tensors, this is mostly a documentation change at this point, but an important design decision) or the implementation of ServingInputReceiver needs to be changed.

@davidsoergel Can you comment on the ServingInputReceiver issue?

I confirm this is annoying.
The previous contract was clear. Whatever the serving_input_fn function returns as "features" is the same thing that model_fn will accept as "features". Now there is this additional constraint for the features to be a dictionary. This is unexpected, undocumented and will make a lot of people stumble.

It is also unnecessary. Yes, you need to name your things properly in communication protocols but the serving_input_fn function is there precisely so that you can unpackage your data from the comms protocol and transform it it the "features" that your model understands.

The two lines where this now break seem to have been written recently and neither needs the features to be a dictionary. The breakage seems to be unintentional:
(saved_model_export_utils.py L163) tests for “if features” which fails on a Tensor.
(estimator.py L1269) accesses features.keys which fails.

It has been 14 days with no activity and this issue has an assignee.Please update the label and/or status accordingly.

@karmel This is another issue you could look at.

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@karmel did you fix this? Should I close it?

A member of the TensorFlow organization has replied after the stat:awaiting tensorflower label was applied.

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

We have a fix in review right now; will update this thread when that is ready.

I was actually looking into this feature right now. Where can I check out the fix?

Nagging Assignee @karmel: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

We have added a TensorServingInputReceiver that can accept and pass along raw tensors. You can use this class instead of the normal ServingInputReceiver if you would like to avoid having your model_fn input wrapped in a dictionary. The tests include an example of using this class with estimators and export_savedmodel.

This is scheduled to be released with v1.7. LMK if you have any questions, and thanks @nkashy1 for the report and samples.

This is not very well documented, I only saw ServingInputReceiver in the doc and got the problem that my features were not a dict.