I’m having a weird issue with resolving a list of objects if anyone has a second to look. I have two objects, Article and History defined like so,

:Article
  {:fields
   {:id {:type (non-null String)}
    :title {:type (non-null String)}
    :description {:type String}
    :aws_path {:type (non-null String)}}}
  :History
  {:fields
   {:id {:type (non-null Int)}
    :user {:type (non-null :User)
           :resolve :History/user}
    :article {:type (non-null :Article)
              :resolve :History/article}
    :section_ref {:type String}}}

:history
  {:type (list :History)
   :args {:offset {:type Int}
          :limit {:type Int}}
   :resolve :query/history}

So the :query/history resolver returns a seq of History objects and the :History/article resolver is always getting the same Article object?

Correct

So, that feels like the issue, perhaps there's some problem with the Article returned by the :History/article resolver? Maybe the query is not valid? I'd assume it's something like select * from Article where history_id = ? perhaps?

Yeah, the actual SQL is select * from articles where article_id = ?. When I log the article_id from the resolver, it’s always coming out as I would expect. Even when I log the output of the query, it comes out as I would expect. However, in the response, it’s just the one article. Here’s the code for the resolver with the logging if it helps,

(defn resolve-history-article
  [context args history]
  (log/warn (str "article ID: " (:article_id history)))
  (log/warn (str "article: " (db/article {:article_id (:article_id history)})))
  (db/article {:id (:article_id history)}))

There's no other errors or logging?

For instance, if a union or interface is involved, and you don't tag the results, that could cause some values to be dropped.

Nope. I can do a quick run of something and get you extra output if you need it

Oh no, this is all very simple SQL. Just a plain select

This kind of thing is pretty foundational to Lacinia. You are saying that your code is receiving the correct values as inputs, returning the correct value(s) as outputs, but that it is not being reflected in the result map.

I have trouble believing that, since all sorts of things would be broken for that to happen.

So close scrutiny is needed ... this is like hitting a bug in your code and thinking there's a compiler error. There generally isn't.

So, are you seeing your resolver invoked the right number of times, and passed the correct values? Are you sure you are pulling the correct property out of the value in order to perform the articles query?

When you say, "just one article" does that mean the :history query returns just one History, or that it returns many History object, but the nested article field is always the same?

“it returns many History object, but the nested article field is always the same”

And it's not possible there's a problem with your data?

Let me correct myself from earlier about the behavior, I just realized I misspoke in a pretty big way. The article_id is correct however the return from the query is always the same. So for this resolver (same as above, just moved some logging around)

(defn resolve-history-article
  [context args history]
  (let [article (db/article [:id (:article_id history)])]
    (log/warn (str "article id: " (:article_id history)))
    (log/warn (str "article: " article))
    article))

WARN  content.resolvers - article id: article-1
WARN  content.resolvers - article: {:id "article-1", :title "much ado about nothing"}
WARN  content.resolvers - article id: article-4
WARN  content.resolvers - article: {:id "article-1", :title "much ado about nothing"}
WARN  content.resolvers - article id: article-3
WARN  content.resolvers - article: {:id "article-1", :title "much ado about nothing"}
WARN  content.resolvers - article id: article-2
WARN  content.resolvers - article: {:id "article-1", :title "much ado about nothing"}

Well, that looks like a problem in db/article doesn't it?

I can't tell you why db/article is apparently ignoring its arguments and returning article-1 every time. That's not in Lacinia's bounds.

I’m not sure so I’m trying to work my way down from the top. I’ll check into the HugSQL and see if I can get more from there. There’s always an explanation, just have to find it. Thanks for the time @hlship!

@admay could it be a pagination issue?

it looks like ur query has an offset and limit

The code does point to db/article has hlship said

@guy I think @hlship is right when he suggests its with the db library. My first query was to come here because HugSQL doesn’t have quite as active of a community as Lacinia. I don’t think it’s the offset and limit because I haven’t put those into the query yet haha

ah right haha

then yeah

What I think might be going, and what I’ve been dreading, is that my cache is acting up. It was a bad plan, poorly executed by yours truly but it’s never acted like this before

yeah that would make sense

especially if the cache is in db/article

Then its just as hlship said